But = has slightly higher precedence than , so that second example is really parsing as if parenthesized ( $result = 3 ), 2, 1; rather than $result = LIST (and you can get the same behavior out of both the sub call and the scalar assignment by explicitly parenthesizing it as $result = ( 3, 2, 1 );). I don't think that disproves anything . . .
Update: using B::Deparse shows the differences:
$ perl -MO=Deparse,-p,-q <<'EOT' sub return_list { return 3, 2, 1 } my $result = return_list(); print "$result\n"; $result = 3, 2, 1; print "$result\n"; $result = ( 3, 2, 1 ); print "$result\n"; EOT sub return_list { return(3, 2, 1); } (my $result = return_list()); print(($result . "\n")); (($result = 3), '???', '???'); print(($result . "\n")); ($result = ('???', '???', 1)); print(($result . "\n")); - syntax OK
Update: Tweaked wording in parenthesized phrase slightly to hopefully make it clearer what I was referring to. I definitely agree it's a tricky case, but I'd say the problem is more "Everything that looks to the eye like a LIST in scalar context isn't" than a case where a LIST in scalar context isn't the value of the final element.
The cake is a lie.
The cake is a lie.
The cake is a lie.
In reply to Re^4: odd =>behavior
by Fletch
in thread odd =>behavior
by tcf03
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |