www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Apparently unsigned types really are necessary

reply Walter Bright <newshound2 digitalmars.com> writes:
http://news.ycombinator.com/item?id=3495283

and getting rid of unsigned types is not the solution to signed/unsigned issues.
Jan 21 2012
next sibling parent reply bcs <bcs example.com> writes:
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.
Jan 21 2012
next sibling parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
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.
Jan 22 2012
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/22/2012 1:44 AM, Jonathan M Davis wrote:
 Whereas others have string feelings

Sometimes I feel like a hashmap.
Jan 22 2012
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/22/12 3:44 AM, Jonathan M Davis wrote:
 Whereas others have string feelings about using unsigned types

My feelings in the matter are definitely integral. Andrei
Jan 22 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/22/2012 4:40 AM, Marco Leise wrote:
 Or is
 this like spaces vs. tabs? 'Cause I'm also a tab user.

I struggled with that for years. Not with my own code, the tabs worked fine. The trouble was when collaborating with other people, who insisted on using tab stop settings that were the evil spawn of satan. Hence, collaborated code was always a mess. Like newklear combat toe to toe with the roosskies, the only way to win is to not play.
Jan 22 2012
next sibling parent reply bcs <bcs example.com> writes:
On 01/22/2012 10:09 AM, Walter Bright wrote:
 On 1/22/2012 4:40 AM, Marco Leise wrote:
 Or is
 this like spaces vs. tabs? 'Cause I'm also a tab user.

I struggled with that for years. Not with my own code, the tabs worked fine. The trouble was when collaborating with other people, who insisted on using tab stop settings that were the evil spawn of satan. Hence, collaborated code was always a mess. Like newklear combat toe to toe with the roosskies, the only way to win is to not play.

The only way to win the whitespace war is to change the rules: My I propose the following modifications to the D lexer: ''' White space may consist of: - A comment between any two tokens. - A single space between tokens that, if adjoined would be a single token. All other white space (including \n \r \t \v, etc.) is forbidden and a lexical error. ''' With these additions, all valid D code will be so hard to read that nobody will ever attempt to read it without first running a re-formatter over it and once that is standard practice, everyone will see it in there own preferred style.
Jan 22 2012
parent "Nick Sabalausky" <a a.a> writes:
"bcs" <bcs example.com> wrote in message 
news:jfhqgv$13f7$1 digitalmars.com...
 On 01/22/2012 10:09 AM, Walter Bright wrote:
 On 1/22/2012 4:40 AM, Marco Leise wrote:
 Or is
 this like spaces vs. tabs? 'Cause I'm also a tab user.

I struggled with that for years. Not with my own code, the tabs worked fine. The trouble was when collaborating with other people, who insisted on using tab stop settings that were the evil spawn of satan. Hence, collaborated code was always a mess. Like newklear combat toe to toe with the roosskies, the only way to win is to not play.

The only way to win the whitespace war is to change the rules: My I propose the following modifications to the D lexer: ''' White space may consist of: - A comment between any two tokens. - A single space between tokens that, if adjoined would be a single token. All other white space (including \n \r \t \v, etc.) is forbidden and a lexical error. ''' With these additions, all valid D code will be so hard to read that nobody will ever attempt to read it without first running a re-formatter over it and once that is standard practice, everyone will see it in there own preferred style.

Hah! I like it :)
Jan 23 2012
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:jfhjd6$lgf$1 digitalmars.com...
 On 1/22/2012 4:40 AM, Marco Leise wrote:
 Or is
 this like spaces vs. tabs? 'Cause I'm also a tab user.


The dirty rotten spacies can pry the tabs from my cold dead hands ;)
 I struggled with that for years. Not with my own code, the tabs worked 
 fine. The trouble was when collaborating with other people, who insisted 
 on using tab stop settings that were the evil spawn of satan. Hence, 
 collaborated code was always a mess.

How is that even *possible*? No matter what a user's tab size is, it's not going to affect anyone else unless they've snuck spaces in there, too.
 Like newklear combat toe to toe with the roosskies, the only way to win is 
 to not play.

In Soviet Russia, the tabstop adjusts YOU! (Nah, I don't know what the hell I mean by that either...)
Jan 23 2012
prev sibling next sibling parent reply bcs <bcs example.com> writes:
On 01/22/2012 01:31 AM, Marco Leise wrote:
 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.

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.
Jan 22 2012
parent captaindet <2krnk gmx.net> writes:
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 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
Jan 22 2012
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Kagamin" <spam here.lot> wrote in message 
news:bhhmhjvgsmlxjvsuwzsb dfeed.kimsufi.thecybershadow.net...
 On Sunday, 22 January 2012 at 09:31:15 UTC, Marco Leise wrote:
 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.

If you ignore type limits, you're asking for trouble. Imagine you have 2 gigs of ram and 3 gig pagefile on 32-bit OS. What is the total size of available memory?

One negative gig, obviously. (I think that means it's positronic...)
Jan 22 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jan 22 2012
next sibling parent torhu <no spam.invalid> writes:
On 22.01.2012 13:49, Jonathan M Davis wrote:
 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.

That'll work just fine, you probably meant '>=' ;)
Jan 22 2012
prev sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 01/22/2012 04:49 AM, Jonathan M Davis wrote:

 Another potentially nasty situation is subtraction. It
 can do fun things when you subtract one unsigned type from another if 

 not careful (since if the result is negative and is then assigned to an
 unsigned integer...).

No need to assign the result explicitly either. Additionally, the subtraction is someties implicit. When the expression has an unsigned in it, the temporary result is unsigned by the language rules since C: import std.stdio; int foo() { return -2; } uint bar() { return 1; } void main() { writeln(foo() + bar()); } The program above prints 4294967295. It may make perfect sense for bar() to return an unsigned type (like arrays' .length property), but every time I decide on an unsigned type, I think about the potentially-unintended implicit conversion to unsigned that may bite the users of bar(). Ali
Jan 22 2012
prev sibling next sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
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.
Jan 22 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
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 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.
Jan 22 2012
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Sunday, 22 January 2012 at 09:31:15 UTC, Marco Leise wrote:
 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.

If you ignore type limits, you're asking for trouble. Imagine you have 2 gigs of ram and 3 gig pagefile on 32-bit OS. What is the total size of available memory?
Jan 22 2012
prev sibling next sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 22.01.2012, 21:44 Uhr, schrieb Kagamin <spam here.lot>:

 On Sunday, 22 January 2012 at 09:31:15 UTC, Marco Leise wrote:
 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.

If you ignore type limits, you're asking for trouble. Imagine you have 2 gigs of ram and 3 gig pagefile on 32-bit OS. What is the total size of available memory?

I can use up to 4GB of that in the address space of my application - the value range of a uint, qed
Jan 22 2012
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Sunday, 22 January 2012 at 22:17:10 UTC, Marco Leise wrote:
 If you ignore type limits, you're asking for trouble. Imagine 
 you have 2 gigs of ram and 3 gig pagefile on 32-bit OS. What 
 is the total size of available memory?

I can use up to 4GB of that in the address space of my application - the value range of a uint, qed

With PAE it's possible to access more than that. AFAIK some web-servers do it.
Jan 22 2012
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 22 Jan 2012 23:38:24 -0500, Kagamin <spam here.lot> wrote:

 On Sunday, 22 January 2012 at 22:17:10 UTC, Marco Leise wrote:
 If you ignore type limits, you're asking for trouble. Imagine you have  
 2 gigs of ram and 3 gig pagefile on 32-bit OS. What is the total size  
 of available memory?

I can use up to 4GB of that in the address space of my application - the value range of a uint, qed

With PAE it's possible to access more than that. AFAIK some web-servers do it.

The OS supports it, but not on a single process. You could achieve the feat with multiple processes. But then again, nobody cares about PAE anymore, just go 64-bit. -Steve
Jan 24 2012
prev sibling next sibling parent reply Mail Mantis <mail.mantis.88 gmail.com> writes:
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.
Jan 22 2012
parent bcs <bcs example.com> writes:
On 01/22/2012 01:42 AM, Mail Mantis wrote:
 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.

http://embed.cs.utah.edu/ioc/
Jan 22 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jan 22 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jan 22 2012
prev sibling next sibling parent Mail Mantis <mail.mantis.88 gmail.com> writes:
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.
Jan 22 2012
prev sibling next sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
On Sun, 22 Jan 2012 13:49:37 +0100, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:

 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.

What's not working with this? Besides a neat idiom for reverse array indexing for (size_t i = a.length; i--; ) writeln(a[i]);
Jan 22 2012
prev sibling next sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 22.01.2012, 13:49 Uhr, schrieb Jonathan M Davis <jmdavisProg gmx.com>:

 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.

That is C style. In D you would write: foreach_reverse(i; 0 .. a.length) {}, which is safe and corrects the two bugs in your code.
 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.

I'm always careful when subtracting unsigned ints for the simple reason that the code working on them would be incorrect if results were negative. One example is subtracting two TickDurations. You always know which one is the lower. The same goes for offsets into files. When you copy the block between two locations you cannot exchange start and end. Imagine we had checked integers now, a proposal that doesn't seem far fetched. Would they scream in pain if I wrote "checked_ulong duration = start_time - end_time"? Yes.
 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

I guess my mental model of integers has grown on the idea that an unsigned integer matches the addressable memory of my computer, and thus it is the natural choice there for array lengths and whatever is limited only by available RAM and comes in positive counts; whereas I 'waste' half the range and have only 'half' a match with signed types. I will put this under "tabs vs. spaces". :)
Jan 22 2012
prev sibling next sibling parent reply equinox atw.hu writes:
Hi,


I noticed I cannot use typedef any longer in D2.
Why did it go?


Regards


Marton Papp
Jan 22 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/22/2012 9:44 AM, equinox atw.hu wrote:
 I noticed I cannot use typedef any longer in D2.
 Why did it go?

typedef turned out to have many difficult issues about when it was a distinct type and when it wasn't.
Jan 22 2012
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:jfhj4v$l2b$1 digitalmars.com...
 On 1/22/2012 9:44 AM, equinox atw.hu wrote:
 I noticed I cannot use typedef any longer in D2.
 Why did it go?

typedef turned out to have many difficult issues about when it was a distinct type and when it wasn't.

Fortunately, you should still be able to get the same effect of typedef with a struct and alias this.
Jan 22 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/23/2012 5:08 AM, Iain Buclaw wrote:
 Walter, what are your views on emitting the names of aliased types to debug?

I don't really have an opinion on it, except that generally when I'm debugging I'm interested in what a type really is, not the layer over it.
Jan 23 2012
parent bearophile <bearophileHUGS lycos.com> writes:
Walter:

 I don't really have an opinion on it, except that generally when I'm debugging 
 I'm interested in what a type really is, not the layer over it.

Both are useful to know for the programmer. See in this enhancement request of mine what both Clang and GCC do: http://d.puremagic.com/issues/show_bug.cgi?id=5004 Bye, bearophile
Jan 23 2012
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Wouldn't it be easier to make the typedef a Phobos solution and end
this debate once and for all?
Sure, the definition won't look as pretty as typedef did, but still...

On Mon, Jan 23, 2012 at 1:22 AM, Nick Sabalausky <a a.a> wrote:
 "Walter Bright" <newshound2 digitalmars.com> wrote in message
 news:jfhj4v$l2b$1 digitalmars.com...
 On 1/22/2012 9:44 AM, equinox atw.hu wrote:
 I noticed I cannot use typedef any longer in D2.
 Why did it go?

typedef turned out to have many difficult issues about when it was a distinct type and when it wasn't.

Fortunately, you should still be able to get the same effect of typedef with a struct and alias this.

-- Bye, Gor Gyolchanyan.
Jan 23 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 22 January 2012 18:05, Walter Bright <newshound2 digitalmars.com> wrote:
 On 1/22/2012 9:44 AM, equinox atw.hu wrote:
 I noticed I cannot use typedef any longer in D2.
 Why did it go?

typedef turned out to have many difficult issues about when it was a distinct type and when it wasn't.

+1 Walter, what are your views on emitting the names of aliased types to debug? -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Jan 23 2012
prev sibling parent "Jakob Bornecrantz" <wallbraker gmail.com> writes:
On Monday, 23 January 2012 at 18:08:51 UTC, Walter Bright wrote:
 On 1/23/2012 5:08 AM, Iain Buclaw wrote:
 Walter, what are your views on emitting the names of aliased 
 types to debug?

I don't really have an opinion on it, except that generally when I'm debugging I'm interested in what a type really is, not the layer over it.

While this is D1 I think it applies to D2 as well. Classes can be substituted for packages the same behavior is still observed. And yes I have code that does this [1]. class A { class Foo {} } class B { class Foo {} } alias A.Foo AFoo; alias B.Foo BFoo; void bar(AFoo f) { BFoo var; bar(var); } src/foo.d(12): Error: function foo.bar (Foo) does not match parameter types (Foo) src/foo.d(12): Error: cannot implicitly convert expression (var) of type foo.B.Foo to foo.A.Foo The first error line is a bit confusing, the second gets it correct. I guess its mostly my fault here, but getting AFoo and BFoo in the first line and then the full print out in the second would be the best for my case at least. Cheers, Jakob. [1] https://github.com/Wallbraker/Charged-Miners/blob/master/src/charge/charge.d
Jan 23 2012
prev sibling next sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 22.01.2012, 18:00 Uhr, schrieb Ali =C3=87ehreli <acehreli yahoo.com>:=


 On 01/22/2012 04:49 AM, Jonathan M Davis wrote:

  > Another potentially nasty situation is subtraction. It
  > can do fun things when you subtract one unsigned type from another =

 you're
  > not careful (since if the result is negative and is then assigned t=

 an
  > unsigned integer...).

 No need to assign the result explicitly either. Additionally, the  =

 subtraction is someties implicit.

 When the expression has an unsigned in it, the temporary result is  =

 unsigned by the language rules since C:

 import std.stdio;

 int foo()
 {
      return -2;
 }

 uint bar()
 {
      return 1;
 }

 void main()
 {
      writeln(foo() + bar());
 }

 The program above prints 4294967295.

 It may make perfect sense for bar() to return an unsigned type (like  =

 arrays' .length property), but every time I decide on an unsigned type=

 I think about the potentially-unintended implicit conversion to unsign=

 that may bite the users of bar().

 Ali

That's a valid point, if the order "foo() + bar()" makes sense and a = negative value is expected. After all foo() and bar() must be related = somehow, otherwise you wouldn't add them. In this case, if the expected = = result is a signed int, I would make bar() return a signed int as well a= nd = not treat that case like array.length!
Jan 22 2012
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, January 23, 2012 10:08:50 Walter Bright wrote:
 On 1/23/2012 5:08 AM, Iain Buclaw wrote:
 Walter, what are your views on emitting the names of aliased types to
 debug?

debugging I'm interested in what a type really is, not the layer over it.

I usually want the aliased type. I can look up what the alias is, but I can't know that something is using an alias if the alias is gone. - Jonathan M Davis
Jan 23 2012
parent "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.742.1327344456.16222.digitalmars-d puremagic.com...
 On Monday, January 23, 2012 10:08:50 Walter Bright wrote:
 On 1/23/2012 5:08 AM, Iain Buclaw wrote:
 Walter, what are your views on emitting the names of aliased types to
 debug?

I don't really have an opinion on it, except that generally when I'm debugging I'm interested in what a type really is, not the layer over it.


That's a pain in the ass for library users. For example, Goldie uses a lot of type sugar so that a nonteminal generated from the rule: <Foo> ::= <Bar> ';' Is usually referred to as type: A: Token_myLang!("<Foo>", "<Bar>", ";") Instead of: B: Token_myLang!( "<Foo>", Token_myLang!(SymbolType.NonTerminal, "<Bar>"), Token_myLang!(SymbolType.Terminal, ";") ) or: C: _Token_myLang!("<Foo>", 47); // Rule ID# The "B" is a rarely-needed unsugared version (which is guaranteed to be unambiguous with other symbols in th grammar). And "C" (or something similar to it) is the true underlying type that's intended purely as an implementation detail - *NOT* for user consumption. The policy of showing types de-aliased breaks proper encapsulation and just detroys all of the above whenever there's a type error (which is the whole point of having those types in the first place).
 I usually want the aliased type.

Same here. I usually find it far more relevent to the code the compiler's referring too. The current way is like having error messages show mangled names or talking in terms of the generated assembly instructions: It totally breaks out of the proper context and level-of-abstraction.
 I can look up what the alias is, but I can't
 know that something is using an alias if the alias is gone.

I hadn't thought of that, that's a good point, too.
Jan 23 2012