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 <b...@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
