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
