Steven Schveighoffer wrote:
"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!
One other thing to contemplate:
What happens if you add a bits32 to a bits64, long, or ulong value? This
needs to be illegal since you don't know whether to sign-extend or not. Or
you could reinterpret the expression to promote the original types to 64-bit
first?
Good point. There's no (or not much) arithmetic mixing bits32 and some
64-bit integral because it's unclear whether extending the bits32
operand should extend the sign bit or not.
This makes the version with 8 and 16 bit types less attractive.
Another alternative is to select the bits type based on the entire
expression. Of course, you'd have to disallow them as public types. And
you'd want to do some special optimizations. You could represent it
conceptually as calculating for all the bits types until the one that is
decided is used, and then the compiler can optimize out the unused ones,
which would at least keep it context-free.
-Steve
That's the intent of defining arithmetic on sign-ambiguous values. The
type information propagates in a complex expression. I haven't heard of
typechecking on entire expression patterns and I think it would be a
rather unclean technique (it means either that there are values that you
can't tell the type of, or that a given value has a context-dependent type).
Andrei
