Stride

[Artur Skawina]

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