postincrement behaviour (differences between dmd and gdc)

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Wed Apr 20 08:39:06 PDT 2011


On 04/20/2011 07:12 AM, KennyTM~ wrote:
> On Apr 20, 11 19:28, Daniel Gibson wrote:
>>
>> I think the DMD way is conformant with the D2 specification, see
>> http://digitalmars.com/d/2.0/operatoroverloading.html
>> "e++ [is rewritten as] (auto t=e, ++e, t)", so x=x++; shouldn't change
>> the value of x. (Yeah, this is for overloading, but the operator should
>> behave the same for simple types).
>>
>> Of course x = x++; still makes no sense and should probably cause a
>> warning or an error.
>
> The D2 specification simply said "x = x++" is illegal. I don't think
> operatoroverloading.html applies to built-in types.
>
> http://www.digitalmars.com/d/2.0/expression.html
> "It is an error to depend on order of evaluation when it is not
> specified. For example, the following are illegal:
>
> i = i++;
> c = a + (a = b);
> func(++i, ++i);
>
> If the compiler can determine that the result of an expression is
> illegally dependent on the order of evaluation, it can issue an error
> (but is not required to). The ability to detect these kinds of errors is
> a quality of implementation issue."
>
> and yes DMD should raise a compiler error.

That's not possible in the presence of aliasing, so it would be an error 
of limited usefulness and one that gives a false sense of security.

The right way is to define the semantics of x = x++ the same as the 
semantics of x = postIncrement(x) where

T postincrement(T)(ref T a) { auto r = a; ++a; return r; }

In that case x = x++ would simply reassign x to itself.


Andrei


More information about the Digitalmars-d mailing list