(I lost track of quotes, so I yanked them all beyond Don's message.)
Don wrote:
The problem with that, is that you're then forcing the 'unsigned is a
natural' interpretation when it may be erroneous.
uint.max - 10 is a uint.
It's an interesting case, because int = u1 - u2 is definitely incorrect
when u1 > int.max.
uint = u1 - u2 may be incorrect when u1 < u2, _if you think of unsigned
as a positive number_.
But, if you think of it as a natural modulo 2^32, uint = u1-u2 is always
correct, since that's what's happening mathematically.
Sounds good. One important consideration is that modulo arithmetic is
considerably easier to understand when two's complement and signs are
not involved.
I'm strongly of the opinion that you shouldn't be able to generate an
unsigned accidentally -- you should need to either declare a type as
uint, or use the 'u' suffix on a literal.
Right now, properties like 'length' being uint means you get too many
surprising uints, especially when using 'auto'.
I am not surprised by length being unsigned. I'm also not surprised by
hexadecimal constants being unsigned. (They are unsigned in C. Walter
made them signed or not, depending on their value.)
I take your point about not wanting to give up the full 32 bits of
address space. The problem is, that if you have an object x which is
>2GB, and a small object y, then x.length - y.length will erroneously
be negative. If we want code (especially in libraries) to cope with such
large objects, we need to ensure that any time there's a subtraction
involving a length, the first is larger than the second. I think that
would preclude the combination:
length is uint
byte[].length can exceed 2GB, and code is correct when it does
uint - uint is an int (or even, can implicitly convert to int)
As far as I can tell, at least one of these has to go.
Well none has to go in the latest design:
(a) One unsigned makes everything unsigned
(b) unsigned -> signed is allowed
(c) signed -> unsigned is disallowed
Of course the latest design has imperfections, but precludes neither of
the three things you mention.
Andrei
