D'oh... Yeah, you're right.
So, for the record, the evaluation order is in fact well-defined: It strictly evaluates higher-precedence operators first, before evaluating any operands of any less deeply nested part of the expression.
That's the source of my confusion: I intuitively expected Perl to only use the operator precedence information to implicitly "add parenthesis" for disambiguation, but then evaluate the expression left-to-right, only recursing into nested sub-expression once they are encountered.
That's two conceptually very different ways of defining evaluation order, but easy to miss because in practice it probably never makes a difference except in special cases involving += and friends.
Well, almost never... :) Here's a demonstration of the evaluation order using tied scalars that report when they're being accessed:
use warnings; use strict; package LoggingScalar { require Tie::Scalar; our @ISA = qw(Tie::StdScalar); sub FETCH { print "fetched: ".(${shift()} // '<undef>')."\n" } } tie my $x, 'LoggingScalar'; tie my $y, 'LoggingScalar'; tie my $z, 'LoggingScalar'; ($x, $y, $z) = qw(x y z); print "---\n"; my @a = ($x, $y . '!', $z);
...which outputs:
--- fetched: y fetched: x fetched: z
As for the mentioned perlop paragraph re. "undefined behavior", I suppose that refers to what Eily says here.
In reply to Re^4: Why does the first $c evaluate to the incremented value in [$c, $c += $_] ?
by smls
in thread Why does the first $c evaluate to the incremented value in [$c, $c += $_] ?
by smls
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |