Warn about do nothing expressions?

[Timon Gehr]

On 03/28/2014 09:59 PM, Justin Whear wrote:
> On Fri, 28 Mar 2014 19:35:20 +0000, Frustrated wrote:
>
>>
>> either way, all increment i, which actually never happens in D. As was
>> pointed out, VS does it properly... D does it wrong. Accept it and stop
>> trying to validate how D does it so you can say D is correct.
>>
>> Not only is it logically wrong, it is not consistent with previous
>> interpretations of other compilers/languages nor with itself. It is
>> wrong on all levels. Just because you believe in unicorns doesn't prove
>> that they exist. All the evidence says you are wrong.
>>
>
> Nope, Frustrated is the one who is dead wrong.
>

Yup. Also, I don't get point of the hostility.

Executing the side effect of an expression after its value has already 
been computed and used certainly seems like the least reasonable choice.

> test.c:
> -----------------------------
> #include <stdio.h>
>
> int main()
> {
> 	int i = 0;
> 	i = i++;
> 	printf("%i\n", i);
> 	return 0;
> }
> -----------------------------
>
> $ gcc test.c && ./a.out
> 0
>
> $ clang test.c && ./a.out
> test.c:7:7: warning: multiple unsequenced modifications to 'i' [-
> Wunsequenced]
>          i = i++;
>            ~  ^
> 1 warning generated.
> 0
>
>
> Both gcc and clang agree that in C, assigning a post-increment to itself
> results in the original value.  At least Clang warns, which is good, but
> D is consistent with C's behavior on this point.
>
> Justin
>

Not really. In C, the evaluation order of assignment and increment is 
actually unspecified and hence a conforming compiler can do it either way.

In D both the "spec" and DMD are confused about the issue of evaluation 
order. (A related fact is that the "spec" contradicts itself on the 
issue of function argument evaluation order.)

http://dlang.org/expression.html

"The following binary expressions are evaluated in an 
implementation-defined order:

AssignExpression, function arguments
...
The evaluation order of function arguments is defined to be left to right."


The example of order-dependent code the "spec" gives is actually the 
example we are talking about here. I'm not sure what "implementation 
defined evaluation order" is supposed to mean though. E.g. if it is just 
the order in which the left and right expression are evaluated before 
the assignment takes place, then the effect of i=i++; is not actually 
ambiguous, as 'i' does not have any side effect and is a fine fully 
evaluated lvalue.

IMHO the most reasonable way out is to just fix a canonical evaluation 
order (i.e. left-to-right) and then stick to that consistently. Under 
left-to-right evaluation order in particular, i=i++; should leave the 
value of i intact. (for int i).

Walter has mentioned on at least one occasion that evaluation should 
become left-to-right everywhere.