Re^6: Why does the first $c evaluate to the incremented value ... (hahaha)

[tye]

Perl does indeed value giving the programmer flexibility in how to write things. That means you are allowed to write things stupidly. When you do, you suffer.

How much speed-up do you think this buggy optimization is worth?

Who declared that this was due to an optimization? It is as likely to be due to a simplification. If you think tying the hands of the implementers is a trivial concern, then you should probably go try to be an implementer of Perl's C code at this point. Go fix this "bug" in the Perl source code. If you don't succeed, at least you might get a much better appreciation for the trade-offs involved in trying to make stupid constructs behave predictably (in the eyes of their too-clever authors).

As to your "lawyer mode", you have jumped to conclusions about how precisely the "don't modify something twice in the same expression" taboo is the same in Perl as in C. Note that I didn't admonish you to not modify something twice in the same expression. Also note that I didn't say anything about "sequence points". I said you should not use a variable in the same statement where you have modified it.

Perl has aliases and whether you get an alias or a copy can be subject to rather subtle factors, arcane implementation details, and (indeed) optimizations. C doesn't have this feature and so C rules don't address it. So simple order of operations is not the only gotcha when writing Perl code. And yet, I don't find it difficult at all to avoid separately using something in the same statement where I've modified it.

I don't really know how much slower the average Perl code would run if a whole class of uses of a bare variable where forced to make a copy of the variable's value just in case somebody got way too clever and decided to modify the variable in that same statement. It might be a bigger performance hit than you seem to expect.

But even if you went and implemented that, you'd likely just get burned later by complaints about how you "broke" some other clever code that was relying on the fact that the value was changing because it wasn't a copy.

Working on Perl's C code is complex enough already. We don't need to make it that much worse via misguided attempts to "define" the behavior of stupidly ambiguous constructs.

[oiskuu]

My "lawyer mode" rant was to show that C is playing catch-up in some areas, and that the rules are anything but clear-cut.

I wouldn't consider perl code that the OP wrote, stupid. In fact I might quite possibly have used the same construct...

[Anonymous Monk]

Its relatively easy to check your code for such constructs because Perl::Critic::Policy is xpaths you can copy this example Perl::Critic::Policy::ValuesAndExpressions::UndefinedBehaviourMaybeQuoteit / $1 not quoted (value not frozen) undefined behaviour

[tye]

Then you simply need to update your best practices to include "Using a variable in the same statement as you separately modify it is stupid".

(Then, when it breaks [as it did] you'll save a lot of time by not trying to convince people that it is a bug. :)