Apparently unsigned types really are necessary

[captaindet]

On 2012-01-22 14:36, foobar wrote:
> On Sunday, 22 January 2012 at 20:01:52 UTC, bcs wrote:
>> On 01/22/2012 01:31 AM, Marco Leise wrote:
>>> Am 22.01.2012, 08:23 Uhr, schrieb bcs <bcs at example.com>:
>>>
>>>> On 01/21/2012 10:05 PM, Walter Bright wrote:
>>>>> http://news.ycombinator.com/item?id=3495283
>>>>>
>>>>> and getting rid of unsigned types is not the solution to
>>>>> signed/unsigned issues.
>>>>
>>>> A quote from that link:
>>>>
>>>> "There are many use cases for data types that behave like pure
>>>> bit strings with no concept of sign."
>>>>
>>>> Why not recast the concept of unsigned integers as "bit vectors
>>>> (that happen to implement arithmetic)"? I've seen several
>>>> sources claim that uint (and friends) should never be used
>>>> unless you are using it for low level bit tricks and the like.
>>>
>>> Those are heretics.
>>>
>>>> Rename them bits{8,16,32,64} and make the current names
>>>> aliases.
>>>
>>> So everyone uses int, and we get messages like: "This program
>>> currently uses -1404024 bytes of RAM". I have strong feelings
>>> against using signed types for variables that are ever going to
>>> only hold positive numbers, especially when it comes to sizes and
>>> lengths.
>>
>> OK, I'll grant that there are a (*extremely* limited) number of
>> cases where you actually need the full range of an unsigned
>> integers type. I'm not suggesting that the actual semantics of the
>> type be modified and it would still be usable for exactly that sort
>> of cases. My suggestion is that the naming be modified to avoid
>> suggesting that the *primary* use for the type is for non negative
>> numbers.
>>
>> To support that position, if you really expect to encounter and
>> thus need to correctly handle numbers between 2^31 and 2^32 (or
>> 63/64, etc.) then you already need to be doing careful analyses to
>> avoid bugs from overflow. At that point, you are already
>> considering low level details and using a "bit vector" type as a
>> number is not much more complicated. The added bonus is that the
>> mismatch between the name and what it's used for is a big red flag
>> saying "be careful or this is likely to cause bugs".
>>
>> Getting people to think of it that way is likely to prevent more
>> bugs that it cause.
>
> I think that we're looking in the wrong corner for the culprit. While
> the unsigned types could have had better names (machine related:
> byte, word, etc..) IMO the real issue here is *not* with the types
> themselves but rather with the horrid implicit conversion rules
> inherited from C. mixed signed/unsigned expressions really should be
> compile errors and should be resolved explicitly by the programmer.
> foo() + bar() can be any of int/uint/long depending on what the
> programmer wants to achieve.
>
> my 2 cents.
>

+1