This was partially discussed before some time ago -
http://www.digitalmars.com/d/archives/digitalmars/D/postincrement_behaviour_differences_between_dmd_and_gdc_47334.html
The following statement has different behaviours in dmd and gdc.
int x;
x = x++;
Where the backend for DMD interprets it as:
tmp = x;
x++;
x = tmp;
And the backend for GDC interprets it as:
x = x;
x++;
Skipping all undefined behaviour/which one is correct talk, an alternative
suggestion would be to treat such nonsensical code as an error - like "Cannot
modify the value of a variable twice in the same expression." - as this kind
of thing I would expect to be almost always a bug.
Regards

This was partially discussed before some time ago -
http://www.digitalmars.com/d/archives/digitalmars/D/postincrement_behaviour_differences_between_dmd_and_gdc_47334.html
The following statement has different behaviours in dmd and gdc.
int x;
x = x++;
Where the backend for DMD interprets it as:
tmp = x;
x++;
x = tmp;
And the backend for GDC interprets it as:
x = x;
x++;
Skipping all undefined behaviour/which one is correct talk, an alternative
suggestion would be to treat such nonsensical code as an error - like "Cannot
modify the value of a variable twice in the same expression." - as this kind
of thing I would expect to be almost always a bug.

Very probable. Also, the dmd interpretation makes even less sense for me. At
least, gdc performs what the probable intent is. But an error is certainly far
better.
denis
--
_________________
vita es estrany
spir.wikidot.com

This was partially discussed before some time ago -
http://www.digitalmars.com/d/archives/digitalmars/D/postincrement_behaviour
_differences_between_dmd_and_gdc_47334.html
The following statement has different behaviours in dmd and gdc.
int x;
x = x++;
Where the backend for DMD interprets it as:
tmp = x;
x++;
x = tmp;
And the backend for GDC interprets it as:
x = x;
x++;
Skipping all undefined behaviour/which one is correct talk, an alternative
suggestion would be to treat such nonsensical code as an error - like
"Cannot modify the value of a variable twice in the same expression." - as
this kind of thing I would expect to be almost always a bug.

Actually, I would have expected postincrement and preincrement to be identical
in this case. It was my understanding that the entire expression to the right
of the assignment operator was evaluated before the assignment was made, but I
guess I could see how that could be open to interpretation with regards to the
postincrement operator.
Regardless, I think that making this sort of case an error would make good
sense.
- Jonathan M Davis

This was partially discussed before some time ago -
http://www.digitalmars.com/d/archives/digitalmars/D/postincrement_behaviour
_differences_between_dmd_and_gdc_47334.html
The following statement has different behaviours in dmd and gdc.
int x;
x = x++;
Where the backend for DMD interprets it as:
tmp = x;
x++;
x = tmp;
And the backend for GDC interprets it as:
x = x;
x++;
Skipping all undefined behaviour/which one is correct talk, an alternative
suggestion would be to treat such nonsensical code as an error - like
"Cannot modify the value of a variable twice in the same expression." - as
this kind of thing I would expect to be almost always a bug.

Actually, I would have expected postincrement and preincrement to be identical
in this case. It was my understanding that the entire expression to the right
of the assignment operator was evaluated before the assignment was made, but I
guess I could see how that could be open to interpretation with regards to the
postincrement operator.

This was partially discussed before some time ago -
http://www.digitalmars.com/d/archives/digitalmars/D/postincrement_behaviour
_differences_between_dmd_and_gdc_47334.html
The following statement has different behaviours in dmd and gdc.
int x;
x = x++;
Where the backend for DMD interprets it as:
tmp = x;
x++;
x = tmp;
And the backend for GDC interprets it as:
x = x;
x++;
Skipping all undefined behaviour/which one is correct talk, an
alternative
suggestion would be to treat such nonsensical code as an error - like
"Cannot modify the value of a variable twice in the same expression."
- as
this kind of thing I would expect to be almost always a bug.

Actually, I would have expected postincrement and preincrement to be
identical
in this case. It was my understanding that the entire expression to
the right
of the assignment operator was evaluated before the assignment was
made, but I
guess I could see how that could be open to interpretation with
regards to the
postincrement operator.

IMHO it should be interpreted as
typeof(p) tmp_p;
typeof(q) tmp_q;
*((tmp_p = p), ++p, tmp_p) = *((tmp_q = q), q++, tmp_q);
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.
Mafi

This was partially discussed before some time ago -
http://www.digitalmars.com/d/archives/digitalmars/D/postincrement_behaviour
_differences_between_dmd_and_gdc_47334.html
The following statement has different behaviours in dmd and gdc.
int x;
x = x++;
Where the backend for DMD interprets it as:
tmp = x;
x++;
x = tmp;
And the backend for GDC interprets it as:
x = x;
x++;
Skipping all undefined behaviour/which one is correct talk, an
alternative
suggestion would be to treat such nonsensical code as an error - like
"Cannot modify the value of a variable twice in the same expression."
- as
this kind of thing I would expect to be almost always a bug.

Actually, I would have expected postincrement and preincrement to be
identical
in this case. It was my understanding that the entire expression to
the right
of the assignment operator was evaluated before the assignment was
made, but I
guess I could see how that could be open to interpretation with
regards to the
postincrement operator.

Yes, I got the idea about this interpretation right after posting (BTW
it should '++q' vs 'q++') ...
In the end should be expanded to autoincrementing address mode, in case
of x86 the equivalent would be "string" ops.

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.

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

suggestion would be to treat such nonsensical code as an error - like "Cannot
modify the value of a variable twice in the same expression." - as this kind
of thing I would expect to be almost always a bug.

Skipping all undefined behaviour/which one is correct talk, an alternative
suggestion would be to treat such nonsensical code as an error - like "Cannot
modify the value of a variable twice in the same expression." - as this kind
of thing I would expect to be almost always a bug.

Thank you for raising this topic again. In my opinion in a modern language,
even a system language, this kind of undefined (and different across different
compilers) is _not_ acceptable.
Another source of some undefined behaviours are function calls.
Two possible solutions for D:
- Turn such situations that lead to undefined behaviour into syntax errors;
- Do define and standardize such behaviours, even if this may cause tiny
performance losses on some CPUs.
Bye,
bearophile

Skipping all undefined behaviour/which one is correct talk, an alternative
suggestion would be to treat such nonsensical code as an error - like "Cannot
modify the value of a variable twice in the same expression." - as this kind
of thing I would expect to be almost always a bug.

Thank you for raising this topic again. In my opinion in a modern language,
even a system language, this kind of undefined (and different across different
compilers) is _not_ acceptable.
Another source of some undefined behaviours are function calls.

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.

Two possible solutions for D:
- Turn such situations that lead to undefined behaviour into syntax errors;
- Do define and standardize such behaviours, even if this may cause tiny
performance losses on some CPUs.
Bye,
bearophile

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.

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