This has little or nothing to do with order of precedence. It has to do with the fact that when side effects happen is undefined. That means that, regardless of any parenthesization, any expression that uses a variable with autoincrement more than once likely has multiple possible acceptable values.
Consider $i++ + $i
The 2nd $i could be either the incremented value or the unincremented value. Parentheses won't change that, because the increment happens at some undefined time. The value of $i++ is defined as the unincremented value, but if you use $i elsewhere in the same statement, Perl does not guarantee you what its value will be.
Caution: Contents may have been coded under pressure.
| [reply] [Watch: Dir/Any] [d/l] [select] |
It's not just order of precedence though, it's that left right shift parsing stuff that lex/yacc/bison/etc do. It makes little sense to me, but that's really what I was talking about. And I'm pretty sure perlop lists the operations as assoc or left — which I assumed was referring to the operator shifting in the parser generator. It hardly matters since there's general agreement that the operations are unreliable. The correct solution is to split up the line (in my opinion).
I wish I had been more clear in the first place. And I wish I'd said split up the line instead of talking incoherently about parens. I actually still kinda wonder if you can get everything to happen in the same order reliably with parens, but it seems not.
| [reply] [Watch: Dir/Any] |