[GDC] Evaluation order: Please update the dmd backend

[Timon Gehr]

On 04/02/2014 09:47 AM, Sarath Kodali wrote:
> On Tuesday, 1 April 2014 at 22:04:43 UTC, Timon Gehr wrote:
>> On 04/01/2014 08:40 PM, Sarath Kodali wrote:
>>> ...
>>>
>>> The evaluation order of assign operators should not be LTR as they have
>>> right associativity. In "a = b = c", c has to be evaluated first, then b
>>> and then a. Similarly, in "a = b + c", "b+c" has to be evaluated first
>>> before a is evaluated. Otherwise it will be very confusing, that in some
>>> cases it is LTR and in some it is RTL.
>>
>> Note that this is after a paragraph that suggests to make evaluation
>> in some cases LTR and in some RTL.
>>
>
> There are 2 evaluation orders that need to be considered while
> evaluating expressions - the evaluation order of operators and the the
> evaluation order of operands of an operator.
> The evaluation order of operators is well defined

(That's a somewhat strong/ill-formed statement, as operator applications 
will in general occur as operands.)

> and is done according to its precedence and
> associativity.

Evaluation order is according to data dependencies. (But C does not even 
guarantee this.) Expressions are _parsed_ according to precedence and 
associativity. Precedence and associativity are determined roughly 
according to common usage to reduce the number of parentheses needed to 
write down a typical expression.

> However the evaluation order of operands for some of the
> binary operators is not defined. D left it undefined for assign
> operator. So in "a=b", the compiler can choose to evaluate a first and
> then b. However in "a=b=c", "b=c" has to be evaluated first

Before the outer assignment, not necessarily before 'a'.

> due to right associativity of '=' operator.
> Similarly in "a=b+c", "b+c" has to be
> evaluated first

Again, evaluated before the assignment, not necessarily before 'a'.

> due to higher precedence of + operator over = operator.
> In both these cases, the right operand of = operator is evaluated first
> and then the left operand.

No, neither of the two cases made any point about the left operand.

> So it naturally follows

I disagree here. Doing it the same way consistently for all operations 
is more 'natural' a priori. Deviations should be justified by actual 
semantics, not parsing details. (E.g. a hypothetical argument might be 
that 'ref' returns are less dangerous with RTL evaluation of 
assignments.) Such arguments, if convincing ones exist, would not 
necessarily generalize to all right-associative expressions.

> that even in the unspecified case (a=b), the right operand should be evaluated first so
> that it is consistent with other cases of = operator. All this means,
> the evaluation order of operands also should be according to the
> associativity of its operator.
> You can test this with other right or left associative binary operators.
>

int a = 1;
int b = (a++)^^(a++)^^(a++); // 1 is a fine value