View mode: basic / threaded / horizontal-split · Log in · Help
April 20, 2011
Re: postincrement behaviour (differences between dmd and gdc)
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.
April 20, 2011
Re: postincrement behaviour (differences between dmd and gdc)
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
April 20, 2011
Re: postincrement behaviour (differences between dmd and gdc)
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
April 21, 2011
Re: postincrement behaviour (differences between dmd and gdc)
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
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home