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.
