New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
each on an anonymous array constructor doesn't complain, but sorta works #11163
Comments
From @briandfoyI thought I'd be clever with each() on an anonymous array that's use Unicode::Normalize; my $string = "éáabcáá\x{65}\x{301}í"; while( my( $index, $grapheme ) = each [$string =~ m/(\X)/g] ) { I know that each() is an array operator and this had little hope of working, I think there should be a warning here, and maybe even a compilation error. Summary of my perl5 (revision 5 version 13 subversion 10) configuration: Platform: Characteristics of this binary (from libperl): |
From @jkeenanOn Mon Feb 28 22:34:48 2011, comdog wrote:
In Perl 5.14, 'perldoc -f each' states (near the end of the doc): ##### Do you think we need warnings or fatals above and beyond this? Thank you very much. |
The RT System itself - Status changed from 'new' to 'open' |
From @briandfoy
Yes, which is why I said so. It doesn't take an EXPR. It takes a VAR. -- |
From @ikegamiOn Mon, Jan 2, 2012 at 10:44 PM, brian d foy <brian.d.foy@gmail.com> wrote:
No, it doesn't just take a "VAR" anymore. $ perl -wE'@a=qw( a b c ); say while ($_) = each(\@a);' $ perl -wE'@a=qw( a b c ); sub f { \@a } say while ($_) = each(f());' It's even possible to have buggy code when passing a "VAR". $ perl -wE'say while ($_) = each(@{ [qw( a b c )] });' Given that C<< each EXPR >> isn't necessarily wrong and C<< each VAR >> Given - some pretty fuzzy heuristics would need to be employed, I'm not sure that anything needs to be done. |
From @cpansproutOn Tue Jan 03 12:59:01 2012, ikegami@adaelis.com wrote:
We could do something similar to this, based on SvTEMP and SvREFCNT: $ perl5.15.6 -we '+sub:lvalue{my$x}->()=3' -- Father Chrysostomos |
From @briandfoy
Both of these still have a named variable attached to the data.
This does not have a named variable and is the point of my original That is, you've said what I initially reported. There are instances where the use of each has no hope of working but -- |
From zefram@fysh.orgbrian d foy wrote:
On the contrary, it works perfectly, doing exactly what the statement The loop will end as soon as one of the constructed arrays has
It works perfectly, and has no surprising limitation. -zefram |
From @briandfoy
That's why I suggested it should be a warning. It's probably not what As for surprising limitations, well, I was surprised. It's another However, this is the end of it for me. Decide what you like and I'll |
From @ikegamiOn Tue, Jan 3, 2012 at 4:14 PM, brian d foy <brian.d.foy@gmail.com> wrote:
Noone said "named variable". We were talking of VAR.
Noone said "named variable". We were talking of VAR. |
From @rjbs* Eric Brine <ikegami@adaelis.com> [2012-01-03T17:10:52]
perlfunc uses EXPR, LIST, VAR, VARIABLE, SOCKET, and so on. There's an -- |
From @rjbs* brian d foy <brian.d.foy@gmail.com> [2012-01-03T17:09:17]
I agree with both of these bits. Yes, if you have a very good mental model of How hard is a warning here? Also, I think Jim's original question was on point: there is a big "warning," -- |
From @davidnicoleach(X) is almost always a mistake when X is built fresh each time |
From zefram@fysh.orgRicardo Signes wrote:
What is the proposed scope of a warning? What's been misunderstood -zefram |
From @davidnicolOn Tue, Jan 3, 2012 at 5:47 PM, Zefram <zefram@fysh.org> wrote:
the warning could say "mutator used in boolean context" for instance, |
From @ikegamiOn Tue, Jan 3, 2012 at 6:47 PM, Zefram <zefram@fysh.org> wrote:
*If* C<pop> warns on a SvTEMP and SvREFCNT check, perldiag should suggest (@{ TEMP_EXPR })[-1] as an alternative to pop @{ TEMP_EXPR } |
From @ikegamiOn Tue, Jan 3, 2012 at 6:22 PM, Ricardo Signes <perl.p5p@rjbs.manxome.org>wrote:
Yes, my reply didn't make much sense. Basically, I didn't want to guess what he meant by named variables, since And anything that starts with @ or % is considered a named variable (at As a Father C pointed out, the correct check relates to TEMP and REFCNT, - Eric |
From @rjbs* Ricardo Signes <perl.p5p@rjbs.manxome.org> [2012-01-03T18:28:55]
...except it wasn't, of course, because this happens with non-reference perl -E 'say while ($_) = each @{[ 1 ]} -- |
From @rjbs* Zefram <zefram@fysh.org> [2012-01-03T18:47:01]
Yes, thanks -- while I /knew/ that, it hadn't hit home. I'll try to think about whether I think this is worth pursuing from a My initial feeling is that this is not going to be worth dealing with in perl. -- |
From @b2gillsThis should warn, or the anonymous array/hash reference should be the while( my($k,$v) = each [0..3] ){ ... } If we make the reference the same on every iteration, it should These should at least warn, since there is no way to break out of the ( These are anonymous array, or hash references created with constant lists ) while( my($k,$v) = each [0..3] ){ ... } while( my($k,$v) = each {0..3} ){ ... } while( my($k,$v) = pop [0..3] ){ ... } (possibly other builtins should be added to this list.) These might be worth warning as well since it suffers the same problem. while( my($k,$v) = each my $arr = [0..3] ){ ... } while( my($k,$v) = each my $hash = {0..3} ){ ... } while( my($k,$v) = pop my $arr = [0..3] ){ ... } These possibly shouldn't warn, or be modified since the value will while( my($k,$v) = each [rand] ){ ... } These possibly shouldn't warn, or be modified since the value can while( my($k,$v) = each [@ARGV] ){ ... } The warning should mention that it is because of interactions of a |
From @jkeenanOn Mon Jan 02 19:17:02 2012, jkeenan wrote:
Historical side-note: Until I had to look at the current documentation I guess that reflects the fact that I learned 'each' 11 years ago at a Now, back to the main thread ... jimk |
Migrated from rt.perl.org#85150 (status was 'open')
Searchable as RT85150$
The text was updated successfully, but these errors were encountered: