On Jun 17, 10 21:04, Don wrote:
KennyTM~ wrote:
On Jun 17, 10 18:59, Don wrote:
Kagamin wrote:
Don Wrote:
(D has introduced ANOTHER instance of this with the ridiculous >>>
operator.
byte b = -1;
byte c = b >>> 1;
Guess what c is!
)
:)
Well, there was issue. Wasn't it fixed?
No. It's a design flaw, not a bug. I think it could only be fixed by
disallowing that code, or creating a special rule to make that code do
what you expect. A better solution would be to drop >>>.
I disagree. The flaw is whether x should be promoted to
CommonType!(typeof(x), int), given that the range of typeof(x >>> y)
should never exceed the range of typeof(x), no matter what value y is.
The range of typeof(x & y) can never exceed the range of typeof(x), no
matter what value y is. Yet (byte & int) is promoted to int.
That's arguable. But (byte & int -> int) is meaningful because (&) is
some what "symmetric" compared to (>>>).
What does (&) do?
(a & b) <=> foreach (bit x, y; zip(a, b))
yield bit (x == y ? 1 : 0);
What does (>>>) do?
(a >>> b) <=> repeat b times {
logical right shift (a);
}
return a;
Algorithmically, (&) needs to iterate over all bits of "a" and "b", but
for (>>>) the range of "b" is irrelevant to the result of "a >>> b".
Actually, what happens to x>>>y if y is negative?
x.d(6): Error: shift by -1 is outside the range 0..32
The current rule is:
x OP y means
cast(CommonType!(x,y))x OP cast(CommonType!(x,y))y
for any binary operation OP.
How can we fix >>> without adding an extra rule?
There's already an extra rule for >>>.
ubyte a = 1;
writeln(typeof(a >>> a).stringof);
// prints "int".
Similarly, (^^), (==), etc do not obey this "rule".
IMO, for ShiftExpression ((>>), (<<), (>>>)) the return type should be
typeof(lhs).
More interesting case is
byte c = -1 >>> 1;
