http://news.ycombinator.com/item?id=3495283

and getting rid of unsigned types is not the solution to signed/unsigned issues.

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.

Rename them bits{8,16,32,64} and make the current names aliases.

Am 22.01.2012, 08:23 Uhr, schrieb bcs <bcs@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.

2012/1/22 Walter Bright <newshound2@digitalmars.com>:
> http://news.ycombinator.com/item?id=3495283
>
> and getting rid of unsigned types is not the solution to signed/unsigned issues.

Would it be sane to add integer overflow/carry runtime checks in -debug builds? This could probably solve such issues, but we'd need some means to avoid this checks when nesessary.

On Sunday, January 22, 2012 10:31:17 Marco Leise wrote:
> Am 22.01.2012, 08:23 Uhr, schrieb bcs <bcs@example.com>:
> > 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.

Whereas others have string feelings about using unsigned types for much of anything which isn't intended for using bitshifts with. Lots of bugs are caused by the use of unsigned integral values. I know that Don wishes that size_t were signed and thinks that it's horrible that it isn't. I suspect that you will find more people who disagree with you than agree with you on this.

Now, whether having bits8, bits16, etc. is a good idea or not, I don't know, but there are a lot of programmers who don't particularly like using unsigned types for normal arithmetic, regardless of what values the variable holds.

- Jonathan M Davis

On 1/22/2012 1:44 AM, Jonathan M Davis wrote:
> Whereas others have string feelings

Sometimes I feel like a hashmap.

On Sunday, January 22, 2012 01:49:02 Walter Bright wrote:
> On 1/22/2012 1:44 AM, Jonathan M Davis wrote:
> > Whereas others have string feelings
> 
> Sometimes I feel like a hashmap.

LOL. I keep forgetting to reread my posts before I post them. I really should fix that...

- Jonathan M Davis

Am 22.01.2012, 10:44 Uhr, schrieb Jonathan M Davis <jmdavisProg@gmx.com>:

> On Sunday, January 22, 2012 10:31:17 Marco Leise wrote:
>> Am 22.01.2012, 08:23 Uhr, schrieb bcs <bcs@example.com>:
>> > 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.
>
> Whereas others have string feelings about using unsigned types for much of
> anything which isn't intended for using bitshifts with. Lots of bugs are
> caused by the use of unsigned integral values. I know that Don wishes that
> size_t were signed and thinks that it's horrible that it isn't. I suspect that
> you will find more people who disagree with you than agree with you on this.
>
> Now, whether having bits8, bits16, etc. is a good idea or not, I don't know,
> but there are a lot of programmers who don't particularly like using unsigned
> types for normal arithmetic, regardless of what values the variable holds.
>
> - Jonathan M Davis

I heard that in the past, but in my own experience using unsigned data types, it did not cause any more bugs. OTOH, textual output is more correct and I find code easier to understand, if it is using the correct 'class' of integers. But this "a lot of programmers who don't particularly like using unsigned types" must come from somewhere. Except for existing bugs in the form of silent under-/overflows that do not appear alarming in a debugger due to their signedness, I've yet to see a convincing example of real world code, that I would write this way and is flawed due to the use of uint instead of int. Or is this like spaces vs. tabs? 'Cause I'm also a tab user.

On Sunday, January 22, 2012 13:40:08 Marco Leise wrote:
> I heard that in the past, but in my own experience using unsigned data types, it did not cause any more bugs. OTOH, textual output is more correct and I find code easier to understand, if it is using the correct 'class' of integers. But this "a lot of programmers who don't particularly like using unsigned types" must come from somewhere. Except for existing bugs in the form of silent under-/overflows that do not appear alarming in a debugger due to their signedness, I've yet to see a convincing example of real world code, that I would write this way and is flawed due to the use of uint instead of int. Or is this like spaces vs. tabs? 'Cause I'm also a tab user.

Down with tabs! ;)

One issue with unsigned integers right off the bat is for loops.

for(size_t i = a.length; i > 0; --i) {}

is not going to work. Another potentially nasty situation is subtraction. It can do fun things when you subtract one unsigned type from another if you're not careful (since if the result is negative and is then assigned to an unsigned integer...). There are probably others, but that's what comes to mind immediately. In general, it comes down to issues with them rolling over and becoming incredibly large values when they go below 0.

Sure, unsigned types can be useful, and if you're careful with them, you can be fine, but there are definitely cases where they cause trouble. Hence, why many programmers argue for not using them unless you actually need them.

- Jonathan M Davis

2012/1/22 Jonathan M Davis <jmdavisProg@gmx.com>:
> Another potentially nasty situation is subtraction. It
> can do fun things when you subtract one unsigned type from another if you're
> not careful...

It is unrelated to unsigned types in any way, isn't it?:

int a = 2_000_000_000;
assert( a + a == 4_000_000_000 ); // fail
assert( a + a == -294_967_296 );   // OK

Overflow bug is often related to casting negative value to unsigned types, yes, but without these types we still may have unexpected behaviour due to this bug, so this is barely a proper solution.