Treating the abusive unsigned syndrome

[Don]

Andrei Alexandrescu wrote:
> D pursues compatibility with C and C++ in the following manner: if a 
> code snippet compiles in both C and D or C++ and D, then it should have 
> the same semantics.
> 
> A classic problem with C and C++ integer arithmetic is that any 
> operation involving at least an unsigned integral receives automatically 
> an unsigned type, regardless of how silly that actually is, 
> semantically. About the only advantage of this rule is that it's simple. 
> IMHO it only has disadvantages from then on.
> 
> The following operations suffer from the "abusive unsigned syndrome" (u 
> is an unsigned integral, i is a signed integral):
> 
> (1) u + i, i + u
> (2) u - i, i - u
> (3) u - u
> (4) u * i, i * u, u / i, i / u, u % i, i % u (compatibility with C 
> requires that these all return unsigned, ouch)
> (5) u < i, i < u, u <= i etc. (all ordering comparisons)
> (6) -u

I think that most of these problems are caused by C enforcing a foolish 
consitency between literals and variables.
The idea that literals like '0' and '1' are of type int is absurd, and 
has caused a torrent of problems. '0' is just '0'.

uint a = 1;
does NOT contain an 'implicit conversion from int to uint', any more 
than there are implicit conversions from naturals to integers in 
mathematics. So I really like the polysemous types idea.

For example, when is it reasonable to use -u?
It's useful with literals like
uint a = -1u; which is equivalent to uint a = 0xFFFF_FFFF.
Anywhere else, it's probably a bug.

My suspicion is, that if you allowed all signed-unsigned operations when 
at least one was a literal, and made everything else illegal, you'd fix 
most of the problems. In particular, there'd be a big reduction in 
people abusing 'uint' as a primitive range-limited int.

Although it would be nice to have a type which was range-limited, 'uint' 
doesn't do it. Instead, it guarantees the number is between 0 and 
int.max*2+1 inclusive. Allowing mixed operations encourages programmers 
to focus the benefit of 'the lower bound is zero!' while forgetting that 
there is an enormous downside ('I'm saying that this could be larger 
than int.max!')

Interestingly, none of these problems exist in assembly language 
programming, where every arithmetic instruction affects the overflow 
flag (for signed operations) as well as the carry flag (for unsigned).