Treating the abusive unsigned syndrome

[Andrei Alexandrescu]

Sergey Gromov wrote:
> 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.

I forgot to mention that that's implied in the bitsNN approach too.

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

Having semantics depend so heavily and confusingly on a compiler switch 
is extremely dangerous. Note that actually quite a lot of code will 
compile, with different semantics, with or without the switch.

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

I don't think we can pursue such a path.


Andrei