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
Document Multiple assignments in assignment ops #16488
Comments
From dp13@sanger.ac.ukThe following are not equivalent, which I found surprising: $ perl -wle 'my $foo = {}; $foo->{b} = defined $foo->{b} ? $foo->{b} : scalar keys %$foo; print $foo->{b}' $ perl -wle 'my $foo = {}; $foo->{b} //= scalar keys %$foo; print $foo->{b}' Assignment operators other than '=' all appear to, in effect, assign the lvalue to undef first (if it does not exist); only then is the new value calculated... a bit like autovivification. This can be confirmed by jumping out of the operation before it completes: $ perl -wle 'my $foo = {}; for (1) { $foo->{b} += 1 + next; } print for keys %$foo' This seems like one of those apparent 'bugs' for which there is a good and interesting reason... but I would have expected to find this behaviour made clear somewhere in the documentation on perlop or, failing that, perlref, and I cannot see it. Is it intentional? I tested on v5.18.2 v5.22.4 which I happened to have lying around at the time and did not find anything relevant in the major perldeltas since then. Daniel -- |
From @cpansproutOn Thu, 05 Apr 2018 09:48:30 -0700, dp13@sanger.ac.uk wrote:
I don’t know offhand whether this is documented, but the difference is explained by the fact that regular assignment (=) evaluates the right-hand side first. (It has to work this way for common idioms like ‘local $x = $x’ to work.) Assignment versions of other operators, however, evaluate the lefthand side first. (In the case of //= &&= etc., it has to be this way, as the lhs determines whether the rhs is evaluated.) -- Father Chrysostomos |
The RT System itself - Status changed from 'new' to 'open' |
From @davidnicolIt's clearly an unwanted autovivification bug, but can we call it an RHS evaluated first: Container slot evaluated first, but as as r-value, does not autoviv assignment op accesses container slot only once, as l-value, which autovivs even when it turns out the assignment isn't going to happen. The documentation does imply that the LHS of an assignment op is going to get dereferenced as which gives us the "good and interesting reason" of "Assignment operators It should be possible to adapt the crazy gymnastics Perl goes through to On Thu, Apr 5, 2018 at 7:36 PM, Father Chrysostomos via RT <
-- |
From @iabynOn Tue, Apr 10, 2018 at 10:49:26AM -0500, David Nicol wrote:
No, it's not worth it. -- |
From @davidnicoland if you really need it you can do it in Perl. "navdora" means $ perl -le 'sub $ perl -le 'sub in practice it would surely make more sense to simply prefer a ternary over On Wed, Apr 11, 2018 at 2:34 AM, Dave Mitchell <davem@iabyn.com> wrote:
-- |
From dp13@sanger.ac.ukFYI re //= Currently it sounds like if you squint at the docs hard enough it is implied. It might be a bug but not worth fixing. For context, Dave Mitchell does a lot of the hard work that someone needs to do deep in the bowels of perl. Daniel -----Original Message----- and if you really need it you can do it in Perl. "navdora" means non-autovivifying defined-or-assign. This was done with 5.22, which is after passing hash elements as subroutine arguments stopped autovivving $ perl -le 'sub $ perl -le 'sub in practice it would surely make more sense to simply prefer a ternary over a //= rather than living with that ugly calling convention. On Wed, Apr 11, 2018 at 2:34 AM, Dave Mitchell <davem@iabyn.com> wrote:
-- -- |
From dp13@sanger.ac.ukSorry, that was meant to be a forward to someone else and I pressed reply instead. Thanks all for looking at this. I am content for this bug to be closed, although the docs could definitely be clearer. I am willing to try writing something. Daniel -----Original Message----- FYI re //= Currently it sounds like if you squint at the docs hard enough it is implied. It might be a bug but not worth fixing. For context, Dave Mitchell does a lot of the hard work that someone needs to do deep in the bowels of perl. Daniel -----Original Message----- and if you really need it you can do it in Perl. "navdora" means non-autovivifying defined-or-assign. This was done with 5.22, which is after passing hash elements as subroutine arguments stopped autovivving $ perl -le 'sub $ perl -le 'sub in practice it would surely make more sense to simply prefer a ternary over a //= rather than living with that ugly calling convention. On Wed, Apr 11, 2018 at 2:34 AM, Dave Mitchell <davem@iabyn.com> wrote:
-- -- |
Migrated from rt.perl.org#133064 (status was 'open')
Searchable as RT133064$
The text was updated successfully, but these errors were encountered: