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.

Am 20.04.2011 13:36, schrieb Dmitry Olshansky:
>>
>> In this case the overall semantics are identical but your expandation
>> looks like gdc's and mine like dmd's. Therefore I think dmd's is more
>> correct although less useful.
>>
>> Generally I think it should just be an error to assign twice in the
>> same expression.
>>
> Why not ? I kind of liked this one:
> a = b = 0;

I also like it and I meant assign the same variable twice in one statement.

Mafi

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

This is something I also came across in java.
When you do that in java it follows the dmd behaviour.

Simply my 2 cents :p