Re: Why does the first $c evaluate to the incremented value in [$c, $c += $_] ?

[vsespb]

I think it's not about precedence.

my $c = 2;
my @a = ("$c", $c+=1);
print "@a";

prints 2, 3

and

my $c = 2;
my @a = ($c, $c+=1);
print "@a";

prints 3, 3

Expressions in lists separated by comma guaranteed to be executed in right order, otherwise

my ($a, $b) = (shift, shift)

would not work
I think problem that some aliasing happening before assigment to @a

[tye]

Yes. Exactly.

It is entertaining when this question comes up, again and again (to see all of the same wrong guesses and conflating Perl and C).

[vsespb]

I understand why aliasing involved when calling function

mysub($c, $c+=1)

But why it's also involved when composing a list?

@a = ($c, $c+=1)

for consistency with function calls? Where is documented?

[tye]

But why [is aliasing] also involved when composing a list?

Most likely because a list can be used like:

( $c, $d ) = ( 1, 2 )

But I'm just guessing. There are usually some subtle implementation details involved. There is often quite complicated history involved as well.

Where is documented?

The types of things that are more likely to change based on changes to Perl having to do with esoteric implementation details, especially optimizations, are often bad things to try to document, IMHO. In any case, I doubt this is documented.

Modifying a variable in the same statement where you use the variable is just something to avoid. Knowing what it does in this version of Perl doesn't mean it will continue to do that in another version of Perl. Having a rough understanding of why it does what it currently does, tends to not be very reliable in allowing even a rather gifted Perl programmer to avoid getting rather different behavior from a very similar construct (and thus being surprised and perhaps resulting in a bug in the code being written).

C is nice in having a standard that pretty clearly lays out this type of thing as officially "undefined behavior". This is a very useful way to push back against clever programers' natural tendency to, from time to time, want to continue to use some overly clever construct.

That C rule and definition don't really apply to Perl. But the motivation for them very much applies to this type of thing in Perl. Trying to tie down exactly how something like this should behave just leads to complex and problematic tying of the hands of the implementers and fixers of bugs in Perl.

So just don't do this type of thing. And don't get too obsessed about why it does what it does. It is more important to understand why it is a construct that you shouldn't be writing. If you've got that down, then you can casually try to better understand what is going on in an attempt to better understand some aspects of Perl. But beware that this might put you at risk of, perhaps unintentionally, relying upon these new assumptions. Best to keep such conclusions you come to marked as guesses or at least vague and not something to rely upon.

[smls]

Well, quote-like operators have higher precedence than +=, so your example can still be explained by the "sub-expressions with higher-precedence operators are evaluated first" rule.

And in the last example, both shift's have the same precedence, so it goes from left to right "as a last resort".

Although, come to think of it, terms are technically supposed to have highest precedence. Yet for some reason, term subexpressions are evaluated last (see my demonstration using tied scalars above).

All things taken together, it seems the rules for expression evaluation order in Perl can be described like so:

1. An expression is viewed as a tree whose branch nodes are operators and whose leaf nodes are terms, constructed in accordance with any grouping parenthesis and the precedence of the involved operators.
2. It follows that sub-expressions which appear as "sibling nodes" in that tree are independent of each other, and if they are all side-effect-free, the order of their evaluation relative to each other is irrelevant. However, if they do have side-effects, it becomes significant. That's where rule 3 comes in:
3. Sibling sub-expressions are evaluated in decreasing order of operator precedence (if they are themselves operators), or last (if they are terms). Sibling of the same precedence group (and only those!) are evaluated left-to-right.

Which still does not answer the question of "Why on earth would it be defined like that?", though. I really don't think it contributes to DWIM. I think it would be more intuitive if the third rule were simply:

3. Sibling sub-expressions are evaluated from left to right.

Maybe it's a performance optimization though, because it allows the compiler to only fetch the values of term once it actually needs to evaluate their parent expression?

[vsespb]

Well, quote-like operators have higher precedence than +=, so your example can still be explained by the "sub-expressions with higher-precedence operators are evaluated first" rule.


What about +0 then ?


my $c = 2;
my @a = ($c+0, $c+=1);
print "@a";
__END__
2 3

and also here result is 3 3:


my $c = 2;
my @a = ($c+=1, "$c");
print "@a";
__END__
3 3


below two examples proof aliasing:


my $c = 2;
my @a = ($c+=2, $c+=1);
print "@a";
__END__
5 5

my $c = 2;
my @a = ($c+=1, $c+=2);
print "@a";
__END__
5 5


also, what about explicit parens:

my $c = 2;
my @a = (($c), ($c+=1));
print "@a";
__END__
3 3

from perlop (about comma):

In list context, it's just the list argument separator, and inserts both its arguments into the list. These arguments are also evaluated from left to right.