On 4 November 2017 at 18:30, Sawyer X <xsawyerx@gmail.com> wrote: > > > On 11/04/2017 01:05 PM, Dave Mitchell wrote: >> On Fri, Nov 03, 2017 at 11:35:28AM +0100, demerphq wrote: >>>> From perlop: >>>> >>>> Assignment operators work as in C. That is, >>>> >>>> $x += 2; >>>> >>>> is equivalent to >>>> >>>> $x = $x + 2; >>>> >>>> although without duplicating any side effects that dereferencing the >>>> lvalue might trigger, such as from C<tie()>. Other assignment >>>> operators work similarly. >>>> >>>> So they're not quite the same. >>> That comment goes back to the >>> a0d0e21ea6ea90a22318550944fe6cb09ae10cda, the 5.000 patch. >>> >>> Personally I read that as documenting what we do, not that it is correct. >> I see it as emphasising that $x will only be evaluated once, and that this >> is intentional. For example >> >> my $s = "abc"; >> sub f : lvalue { print "In f()\n"; $s } >> f .= "def"; >> >> only calls f() once. >> >>> Isn't that non-obviousness a byproduct of the "12" vs "4123" discrepancy? >>> >>> It seems to me that if this behavior was well defined then both this >>> question and the discrepancy would go away. >> From my experience of working on multiconcat, I think it would be a very >> hard task to form a well-defined list of behaviours for all the >> interactions of tie, overload, number of uninit warnings, etc. > > To (hopefully minimally) interject here, would it be valuable if we were > able to do it? Personally I think so yes. Whether it is practical is another matter. BTW, at work just today someone posted about a variant of this: my %hash; $hash{foo} += scalar keys %hash; which sets foo to 1, whereas $hash{foo}= $hash{foo} + scalar keys %hash; sets it to 0. The reason for the discrepancy is that the mutator triggers an optimization that means that we do only one hash operation (fetch_or_create), not two (fetch followed by store). Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Previous