Stride

[Jonathan M Davis]

On Monday, February 13, 2012 22:24:38 Artur Skawina wrote:
> The important thing here is - the order absolutely *must* be foo(), then
> bar(), what happens under the hood is completely irrelevant. The reason is
> simple - if this is not what happens then it's a serious compiler bug. And
> if you can't rely on the order then it just shouldn't be documented. The
> order /could/ be undefined, so specifying it means the programmer has to
> assume he/she /can/ count that the compiler follows it - otherwise defining
> it wouldn't make any sense.
> IOW having the order defined, but not implemented, causes bugs that wouldn't
> be there without such definition; hence one has to assume that it *is*
> implemented (modulo unknown compiler bugs of course).
> Undefining the order is a much better solution than suggesting that users
> should assume the compiler is broken. It can always be re-defined later,
> switching from defined to undefined is not as easy.

I'm not arguing that the order _shouldn't_ be defined and guaranteed. I'm just 
saying that I wouldn't trust the compiler to make such guarantees. If you find 
that bar gets evaluated before foo, then by all means, report it. But unless 
one of the dmd devs verifies in the code that it does indeed guarantee left-to-
right evaluation of foo() ~ bar() even with operator overloading, I would 
consider it a bad idea to rely on it. Given that lowering is involved, I think 
that there's a high chance that the order is just as defined as directly 
calling op!"~"(foo(), bar()) would be.

- Jonathan M Davis