Stride

[Artur Skawina]

On 02/13/12 23:39, Timon Gehr wrote:
> 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.

In theory it shouldn't, but it's much better to have a situation where the spec
can be incrementally improved, than to end up having to make backwards incompatible
changes later, when for example it's found that fixing some corner cases would be
too hard.
And I keep saying that *if* the order is defined then it should be followed, 
otherwise it would be better to document the actual behavior; that's all.

Is L-T-R for function arg evaluation documented somewhere, btw? The "expression"
dlang.org page has it as implementation-defined.

artur