Assignment operators work as in C. That is,

$a += 2;
[download]

is equivalent to

$a = $a + 2;
[download]

although without duplicating any side effects that dereferencing the lvalue might trigger, such as from tie(). Other assignment operators work similarly. The following are recognized:

**=    +=    *=    &=    <<=    &&=
       -=    /=    |=    >>=    ||=
                  .=    %=    ^=           //=
             x=
[download]

One of these two things is wrong. Either the documentation or the implementation. My vote is for the implementation.

Although as I said, it's such a contrived example that I can understand why it wouldn't be a big deal, and that the optimization benefits would be worth the sacrifice.

I'm not being silly. If you disagree with my original explanation, then please respond to it. Perhaps you should start by re-reading it since you responded to:

is it a bug or feature?

Neither.

with "You're right tye, it's a bug." That certainly makes me suspect that you are capable of reading what I wrote with more attention than you did originally. :)

I get where you're coming from since you're trying to explain WHY they are different.

No, I'm not. I'm saying that they aren't different (in any meaningful or important way).

However, implementations details including optimizations don't matter.

Well, if you write code well, then they won't matter. This is exactly the kind of code where they do actually matter (which is exactly why writing such code is discouraged).

One of these two things is wrong. Either the documentation or the implementation.

No. The documentation is right. And I haven't seen any evidence demonstrating that any of the various implementations of Perl violate that part of the documentation.

Both forms do equivalent things. Minor details about exactly what they do vary from implementation to implementation (and between the two forms at least in some implementations). Those minor details mostly don't matter. But you can write pathological code that exposes some of those minor differences.

The documentation certainly does not say that both forms are identical in every minor detail. There are lots of other details that might be different between the two forms (at least in some implementations of Perl) without violating the documentation. Do they always return the same value? In a list context? In a scalar context? Do they treat a tied variable identically? Do they act the same when used as an L-value? When given a list or array on the left or on the right? Any of those could be different in some cases with the two forms still being similar enough in enough (more important) respects such that they can be correctly declared as "equivalent".

I have a little tool called 'say' that mostly just prints out the value of a Perl expression such as when given on the command line:

 % say "@x= @x || 2..4"
2
3
4
 % say "@x ||= 2..4"
Can't modify array dereference in logical or assignment (||=)...

 % say
{ my $x; sub f:lvalue { $x += shift @_; return $x } }
f(2) ||= 3, f(10)
__END__
2
12
 % say
{ my $x; sub f:lvalue { $x += shift @_; return $x } }
f(2)= f(2) || 3, f(10)
__END__
2
14
[download]

There may already be implementations of Perl where the original ||= code prints 0 and/or implementations where the "= ... ||" code prints 1.

There might be an early version of Perl where there was not yet a dedicated orassign op-code and $x ||= $y actually got compiled to the same op-code tree as $x= $x || $y, even though that results in slightly less efficient code. A future version of Perl might notice that, in $x= $x || $y, the two instances of $x are identical and decides to take advantage of that to implement more efficient code that behaves like the $x ||= $y case in the version of Perl Anonymous Monk used.

The two forms are equivalent. They are even equivalent to the point that either one might print 0 or 1, depending on subtle implementation details including optimizations that can easily change without any significant notice being given. It is good that the implementers and maintainers have that minor wiggle room so that future improvements, even optimizations, are possible (and/or easier).

- tye        

I get what you're saying, but I still disagree. It may be an optimization quirk, but it's also still a bug.

The extended assignment operators are there to provide a syntax shortcut, and yes, to provide the compiler with additional information it can use to optimize the implementation. However, you can't redefine changes in behavior as simple "wiggle room". There is no, this will equal either 0 or 1. This is programming, it needs to have defined behavior.

$ perl -e '$a{0} = scalar keys %a; print $a{0}'
0
$ perl -e '$a{0} = $a{0} || scalar keys %a; print $a{0}'
0
$ perl -e '$a{0} ||= scalar keys %a; print $a{0}'
1
$ perl -e '$a{0} = $t ||= scalar keys %a; print $a{0}'
0
[download]

Yes, it's an edge case. Yes, it's an edge case that is an acceptable variance in behavior for me at least. But that variance in behavior is still a bug (in my opinion ...).