Apparently unsigned types really are necessary

[foobar]

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.