Signed word lengths and indexes

Don nospam at nospam.com
Thu Jun 17 12:24:52 PDT 2010


Andrei Alexandrescu wrote:
> 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.
>> Actually, what happens to x>>>y if y is negative?
>>
>> 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?
> 
> Wait a minute. D should never allow an implicit narrowing conversion. It 
> doesn't for other cases, so isn't this a simple bug?

It'll make it illegal, but it won't make it usable.
I think the effect of full range propagation will be that >>> will 
become illegal for anything other than int and long, unless it is 
provably identical to >>.
Unless you do the hideous  b >>> cast(typeof(b))1;

I think every D style guide will include the recommendation, "never use 
 >>>".

A question I have though is, Java has >>>. Does Java have these problems 
too?


More information about the Digitalmars-d mailing list