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
