Front page | perl.perl5.porters |
Postings from November 2017
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