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.
