On Monday, 25 May 2015 at 15:35:02 UTC, Jonathan M Davis wrote:
would hope good code would avoid. But defining the order of evaluation as left-to-right, doesn't make those problems go away. At best, it makes them consistent, and that may be worth it, but it's not a silver bullet. And it takes optimization opportunities away from the compiler, since in many cases, it can reorder how the expression is evaluated to make better use of the registers and whatnot. So, forcing the order of
One of C's design mistakes is to make assignments expressions and not statements. Favouring terseness over correctness, an issue the C follow-up language Go partially recognized by turning "++" and "--" into statements.
I agree with you that if an expression depends on evaluation order it is most likely either buggy or prone to become buggy when the program is modified later on. So it is reasonable to define it as illegal and leave it to a sanitizer. (Of course, the exception is shortcut operators like "&&" and "||", which already are have strict evaluation order).
Being able to change evaluation order can provide optimization opportunities that cannot be fixed by having the compiler infer it due to aliasing issues. Not only due to registers, but also because of barriers, aliasing, lookup-tables, sub-expressions etc…
The downside to not having a strict evaluation order is contexts where you want to use multiple generator calls in a single expression (like a numeric range or random number generator), so it goes against the whole "range iterators" approach which will lead to lengthy expressions that do contain side effects.
So essentially D does not have any other reasonable option than strict LTR evaluation, since it is making "gigantic" expressions with generators in them a selling point.
You have to support what you market as a major feature whether that is done by having dedicated "range-operators" that have strict evaluation order or by making all expressions strict..
