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
map sometimes does and sometime does not copy vals #15590
Comments
From @cpansproutI would expect these two to be equivalent: $ ./perl -Ilib -le '$x = 4; sub {\@_; for (map {$_[0]} 1) { $_=3 } }->($x); print $x' This is with v5.25.4-89-g05bda26, but the behaviour is ancient. I get the same results with 5.8.7. Depending on internal flags, map may or may not copy the value returned from the block. I believe it should always copy, but I wanted to check to make sure before making the change. -- Father Chrysostomos |
From zefram@fysh.orgFather Chrysostomos wrote:
Not sure why you'd expect them to be equivalent. You're basically asking $ perl -lwe '$x = 4; sub { $_[0] = 3; }->($x); print $x' However, these two methods of using $_[0]/shift disagree on which one $ perl -lwe '$x = 4; sub { ${\shift} = 3; }->($x); print $x' Then there's a third obvious way of using the maybe-lvalue that yields $ perl -lwe '$x = 4; sub { for($_[0]) { $_ = 3; } }->($x); print $x' So it's consistently inconsistent. -zefram |
The RT System itself - Status changed from 'new' to 'open' |
From @cpansproutOn Mon Sep 05 23:05:36 2016, zefram@fysh.org wrote:
They are equivalent in that they return values that are referentially identical, such that \$_[0] == \shift.
The equivalence is what I’m looking for. Either map’s return value should be referentially identical to the value returned from the block, or it should not be. map should be consistent either way. Make sense? (Fixing this is just a matter of checking that the refcount is 1 before deciding to skip copying something already marked SvTEMP.)
And the fact the the AvREAL flag on @_ makes a difference is a bug, too. -- Father Chrysostomos |
Migrated from rt.perl.org#129208 (status was 'open')
Searchable as RT129208$
The text was updated successfully, but these errors were encountered: