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
