Signed word lengths and indexes

[Andrei Alexandrescu]

Don wrote:
> 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 
>  >>>".

Three times. Three times I tried to convince Walter to remove that crap 
from D - one for each '>'. Last time was as the manuscript going out the 
door and I was willing to take the flak from the copyeditors for the 
changes in pagination. Just like with non-null references, Walter has 
framed the matter in a way that makes convincing extremely difficult. 
That would be great if he were right.

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

Java is much more conservative with implicit conversions, so they 
wouldn't allow the assignment without a cast. Beyond that, yes, the 
issues are the same.


Andrei