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 <[email protected]>:
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.
