Integers vs. Machine words [Bikeshed] (was re: dmd 1.046 and 2.031 releases)

[Joel C. Salomon]

I'm switching newsgroups for a bicycle-shed-color discussion.

In digitalmars.D.announce, Derek Parnell wrote:
> On Sun, 05 Jul 2009 23:35:24 -0700, Walter Bright wrote:
>> Derek Parnell wrote:
>>> But I expected the compiler to complain that an unsigned value cannot by
>>> implicitly converted to a signed value as that results in loss of
>>> *significant* bits.
>> 
>> We tried for a long time to come up with a sensible way to deal with the 
>> signed/unsigned dichotomy. We finally gave that up as unworkable. 
>> Instead, we opted for a method of significant bits, *not* how those bits 
>> are interpreted. -6 and 250 are the same bits in byte and ubyte, the 
>> difference is interpretation.
> 
> I am disappointed. I hope that you haven't stopped working on a solution to
> this though, as allowing D to silently permit bugs it could prevent is not
> something we are hoping for.

Seems to me there are two different concepts that might be separable:
fixed-precision integers and machine words.  Machine words are raw data:
bits, bytes, words (of various sizes).  Then there are interpretations
of these, as signed/unsigned ints, as pointers, as floating-point data,
&c.  Might it be reasonable to distinguish raw words from the integral
types?

I.e., on x86-32 there might be the types byte = word8, short word =
word16, word = word32, long word = word64.  These are neither signed nor
unsigned, e.g., a word8 can be assigned a value in the range -128--255,
but you cannot say if(word1 < word2).  Build std.bitfield on these.
Disallow conversions between sizes without casts, and provide distinct
zero-fill & sign-extension casts.

Distinct from these are the integral types: (u)int[8. 16, 32, 64, ...].
 Allow implicit conversion from word to integral types, and give integer
literals a wordn type.  (A warning in cases like uint x = -5 or int8 y =
350 might be handy, though.)  Now there can be room to tighten the rules
for signed/unsigned conversions.

Another possible use for this might be on a machine that can optionally
trap on integer overflow:  Define overflow on (u)intn to be a --
possibly untrapped -- run-time error, but explicitly *allow* overflow in
arithmetic on wordn types.  (Otherwise, only bitwise operators have much
meaning on the wordn types.)

—Joel Salomon