Signed word lengths and indexes

[Andrei Alexandrescu]

Walter Bright wrote:
> Andrei Alexandrescu wrote:
>> Walter Bright wrote:
>>> Steven Schveighoffer wrote:
>>>> On Thu, 17 Jun 2010 15:24:52 -0400, Don <nospam at nospam.com> wrote:
>>>>
>>>>>
>>>>> A question I have though is, Java has >>>. Does Java have these 
>>>>> problems too?
>>>>
>>>> Java doesn't have unsigned values, so it's necessary to use regular 
>>>> int's as bitmasks, hence the extra operator.
>>>
>>> The reason D has >>> is to cause an unsigned right shift to be 
>>> generated without needing to resort to casts as one has to in C.
>>>
>>> The problem with such casts is they wreck generic code.
>>
>> No.
>>
>> http://www.digitalmars.com/d/2.0/phobos/std_traits.html#Unsigned
>>
>> void fun(T)(T num) if (isIntegral!T)
>> {
>>     auto x = cast(Unsigned!T) num;
>>     ...
>> }
> 
> It's not a perfect replacement, as in if T is a custom integer type, you 
> have to extend the template to support it.

Let me think when I wanted an unsigned shift against an 
arbitrarily-sized integer. Um... never?

> Furthermore, now your BigInt 
> custom type also has to support a cast to unsigned just so it can right 
> shift.

BigInt is a superficial argument. Unless you're willing to flesh it out 
much better, it can be safely dropped.

> Also, T may not be readily identifiable, so you'd have to write:
> 
>     cast(Unsigned!(typeof(expr)) expr;

It's not like shift occurs often enough to make that an issue.

Note that your argument is predicated on using signed types instead of 
unsigned types in the first place, and tacitly assumes the issue is 
frequent enough to *add a new operator*. Yet unsigned shifts correlate 
naturally with unsigned numbers.

So what is exactly that is valuable in >>> that makes its presence in 
the language justifiable?


Andrei