Comment #0 by ellery-newcomer — 2010-01-23T08:46:43Z
Spec says a op= b is semantically equivalent to a = a op b.
Spec lies, or at least is at odds with DMD.
Comment #1 by smjg — 2010-09-23T06:16:30Z
I assume you're talking about the fact that code like this fails:
----------
class Qwert {
Qwert opAdd(Qwert yuiop) { return this; }
}
void main() {
Qwert asfdg = new Qwert;
asdfg += asdfg;
}
----------
I entirely agree that this code should work, on the bases both of common sense and of this spec.
Comment #2 by clugdbug — 2012-01-18T12:06:10Z
Apart from Stewart's comment, there's also the case of >>>.
a >>>= b is different to a = a >>> b, if a is short or byte.
(The first does an unsigned shift, the second does a signed shift).
Comment #3 by timon.gehr — 2012-01-18T12:18:44Z
The same halds for other binary operators. The sentence should probably just be removed from the spec.
Comment #4 by smjg — 2012-01-18T16:31:48Z
(In reply to comment #2)
> Apart from Stewart's comment, there's also the case of >>>.
>
> a >>>= b is different to a = a >>> b, if a is short or byte.
>
> (The first does an unsigned shift, the second does a signed shift).
Oh yes, that crazy abomination that is promotion. Suppose you have
byte a = cast(byte) 0b11110000; // why does it insist on a cast?
a = a >>> 3;
then what actually happens is
0b11110000 >> 3
promote to int
0b1111111111110000 >> 3
apply shift
0b0001111111111110
convert back to a byte
0b11111110
If you shift by 25 or more (17 or more for short), you'll start to see the zero bits come through.
Comment #5 by timon.gehr — 2012-01-18T16:36:54Z
(In reply to comment #4)
> byte a = cast(byte) 0b11110000; // why does it insist on a cast?
Because 240 does not fit inside the range -128 to 127.
static assert(0b11110000 != cast(byte)0b11110000);
Comment #6 by github-bugzilla — 2012-01-23T14:15:24Z