Stride

[Timon Gehr]

On 02/13/2012 11:27 PM, Artur Skawina wrote:
> On 02/13/12 22:58, Jonathan M Davis wrote:
>> 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
>
> I'm not arguing that it _should_ be defined - just pointing out that the fact
> that it currently _is_ means one should be able to assume it works. After all
> there's only one D frontend and it comes from the vendor that also effectively
> controls the language spec - so it's reasonable to expect things that are
> documented, but could have been omitted, to work. If the compiler does not
> currently implement these spec parts it would be much better to say that
> the order *will* be L-T-R, but right now is undefined. That way users won't
> be mislead and if somebody else decides do to a D compiler it will be clear
> what should happen. Switching later from L-T-R to Undefined breaks backwards
> compatibility, but doing it the other way is harmless.
>
> artur

D the language requires L-T-R for both binary operators and function 
invocation. If DMD the compiler does not implement this in all cases 
then that is a bug. Why should a compiler bug have any influence 
whatsoever on the *language specification* ? I cannot follow.

Order of evaluation for assignment expressions seems to be undefined in 
DMD 2.057, the following code has differing behavior in presence or 
absence of the optimization flags:

int foo(int x){writeln(x);return 0;}

ref int bar(int a,int b,int c){return *(new int);}

void main(){
     bar(foo(0),foo(1),foo(2))=bar(foo(3),foo(4),foo(5));
}

FWIW, I didn't find any other counter-examples.