Treating the abusive unsigned syndrome

[Sergey Gromov]

Tue, 25 Nov 2008 11:06:32 -0600, Andrei Alexandrescu wrote:

> I remembered a couple more details. The names bits8, bits16, bits32, and 
> bits64 were a possible choice for undecided-sign integrals. Walter and I 
> liked that quite some. Walter also suggested that we make those actually 
> full types accessible to programmers. We both were concerned that they'd 
> add to the already large panoply of integral types in D. Dropping bits8 
> and bits16 would reduce bloating at the cost of consistency.
> 
> So we're contemplating:
> 
> (a) Add bits8, bits16, bit32, bits64 public types.
> (b) Add bit32, bits64 public types.
> (c) Add bits8, bits16, bit32, bits64 compiler-internal types.
> (d) Add bit32, bits64 compiler-internal types.
> 
> Make your pick or add more choices!

I'll add more.  :)

The problem with signed/unsigned types is that neither int nor uint is a
sub-type of one another.  They're essentially incompatible.  Therefore a
possible solution is:

1.  Disallow implicit signed <=> unsigned conversion.

2.  For those willing to port large C/C++ codebases introduce a compiler
compatibility switch which would add global operators mimicking the C
behavior:

uint opAdd(int, uint)
uint opAdd(uint, int)
ulong opAdd(long, ulong)
etc.

This way you can even implement compatibility levels: only C-style
additions, or additions with multiplications, or complete compatibility
including the original signed/unsigned comparison behavior.