laziness, impatience, and hubris | |
PerlMonks |
Re^3: Pre vs Post Incrementing variablesby BrowserUk (Patriarch) |
on Sep 12, 2010 at 17:41 UTC ( [id://859883]=note: print w/replies, xml ) | Need Help?? |
It's got nothing to do with operand evaluation order. Who said anything about operand evaluation order? (How could there be an operand evaluation order for a unary operator.) I'll come back to this. It has to do with pre-increment returning lvalues.
So, not an lvalue. is more or less equivalent to ... alias Ah! That well know Perl keyword 'alias'.... It's got nothing to do with Hm. "It" has everything to do with the fact that the evaluation order of sub-expressions is unspecified. Where "it" is the contradictory and useless behaviour, observed by the OP, and repeated in my post. Because, if were specified, then the implementation would not be able to get away with producing those totally illogical, useless results, for those unwise or unknowing enough to try and use, what could be a useful behaviour. Your attempts to explain how the implementation produces these useless results from this unspecified and therefore deprecated code, does naught to detract from the reason why it has been possible to enshrine this broken behaviour in the implementation. The fact that f( ++$n, ++$n ) passes an alias to $n, rather than the value resulting from the preincrement, is just another broken behaviour. It is equivalent to C allowing:
Which it doesn't:
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
In Section
Seekers of Perl Wisdom
|
|