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