Signed word lengths and indexes

KennyTM~ kennytm at gmail.com
Thu Jun 17 07:20:03 PDT 2010


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;
>>



More information about the Digitalmars-d mailing list