Signed word lengths and indexes

[KennyTM~]

On Jun 17, 10 23:50, Don wrote:
> KennyTM~ wrote:
>> 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 (>>>).
>
> See below. It's what C does that matters.
>
>>> Actually, what happens to x>>>y if y is negative?
>>>
>>
>> x.d(6): Error: shift by -1 is outside the range 0..32
>
> If y is a variable, it actually performs x >>> (y&31);
> So it actually makes no sense for it to cast everything to int.
>
>>> 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".
>
> The logical operators aren't relevant. They all return bool.
> ^^ obeys the rule: typeof(a^^b) is typeof(a*b), in all cases.
>
>> IMO, for ShiftExpression ((>>), (<<), (>>>)) the return type should be
>> typeof(lhs).
>
> I agree that would be better, but it would be a silent change from the C
> behaviour. So it's not possible.

Too bad.