Treating the abusive unsigned syndrome

[Denis Koroskin]

27.11.08 в 03:46 Sean Kelly в своём письме писал(а):

> Andrei Alexandrescu wrote:
>> Sean Kelly wrote:
>>> Don wrote:
>>>>
>>>> Although it would be nice to have a type which was range-limited,  
>>>> 'uint' doesn't do it. Instead, it guarantees the number is between 0  
>>>> and int.max*2+1 inclusive. Allowing mixed operations encourages  
>>>> programmers to focus the benefit of 'the lower bound is zero!' while  
>>>> forgetting that there is an enormous downside ('I'm saying that this  
>>>> could be larger than int.max!')
>>>
>>> This inspired me to think about where I use uint and I realized that I  
>>> don't.  I use size_t for size/length representations (largely because  
>>> sizes can theoretically be >2GB on a 32-bit system), and ubyte for  
>>> bit-level stuff, but that's it.
>>  For the record, I use unsigned types wherever there's a non-negative  
>> number involved (e.g. a count). So I'd be helped by better unsigned  
>> operations.
>
> To be fair, I generally use unsigned numbers for values that are  
> logically always positive.  These just tend to be sizes and counts in my  
> code.
>
>> I wonder how often these super-large arrays do occur on 32-bit systems.  
>> I do have programs that try to allocate as large a contiguous matrix as  
>> possible, but never sat down and tested whether a >2GB chunk was  
>> allocated on the Linux cluster I work on. I'm quite annoyed by this  
>> >2GB issue because it's a very practical and very rare issue in a weird  
>> contrast with a very principled issue (modeling natural numbers).
>
> Yeah, I have no idea how common they are, though my guess would be that  
> they are rather uncommon.  As a library programmer, I simply must assume  
> that they are in use, which is why I use size_t as a matter of course.
>
>
> Sean

If they can be more than 2Gb, why can't they be more than 4GB? It is  
dangerous to assume that they won't, that's why uint is dangerous. You  
exchange one additional bit of information for safety, this is wrong.

Soon enough we won't use uints the same way we don't use ushorts (I should  
have asked if anyone uses ushort these day first, but there is so little  
gain to use  ushort as opposed to short or int that I consider it  
impractical). 64bit era will give us 64bit pointers and 64 bit counters.  
Do you think you will prefer ulong over long for an additional bit? You  
really shoudn't.

My proposal

Short summary:
- Disallow bitwise operations on both signed types and unsigned types,  
allow arithmetic operations
- Discourage usage of unsigned types. Introduce bits8, bits16, bits32 and  
bits64 as a replacement
- Disallow arithmetic operations on bits* types, allow bitwise operations  
on them
- Disallow mixed-type operations (compare, add, sub, mul and div)
- Disallow implicit casts between all types
- Use int and long (or ranged types) for length and indices with runtime  
checks (a.length-- is always dangerous no mater what CT checks you will  
make).
- Add type constructors for int/uint/etc: "auto x = int(int.max + 1);"  
throws at run-time


The two most common uses of uints are:

0) Bitfields or masks, packed values and hexademical constants (bitfields  
later on)
1) Numbers that can't be negative (counters, sizes/lengths etc)


Bitfields

Bitfields are handy, and using of an unsigned type over a signed is surely  
preferable. Most common operations on bitfields are bitwise AND, OR,  
(R/L)SHIFT and XOR. You shouldn't substruct from or add to them, it is an  
error in most cases. This is what new bits8, bits16, bits32 and bits64  
types should be used for:

bits32 argbColor;
int alphaShift = 24; // any type here, actually

// shift
bits32 alphaMask = (0xFF << alphaShift); // 0xFF is of type bits8

auto value2 = value1 & mask; // all 3 are of type bits*

// you can only shift bits, result is in bits, too, i.e. the following is  
incorrect:
int i = -42;
int x = (i << 8); // An error
// 1) can't shift value of type int
// 2) can't assign valus of type bits32 to variable of type int

// ubyte is still handy sometimes (color should belong to [0..255] range)
auto red = (argbColor & alphaMask) >> alphaShift; // result is in bits32,  
use explicit cast to convert it to target data type:

ubyte red = cast(ubyte)((argbColor & alphaMask) >> alphaShift);

// Alternatively:
ubyte alpha = ubyte((argbColor & alphaMask) >> alphaShift);

Type constructor throws an error if source value (which is of type bits32  
in this example) can't be stored in ubyte. This might be a replacement for  
signed/unsigned methods.

int i = 0xFFFFFFFF; // an error, can't convert value of type bits32 to  
variable of type int
int i = int.max + 1; // ok
int i =  int(int.max + 1); // an exception is raised at runtime

int i = 0xABCD - 0xDCBA; // not allowed. Add explicit casts

auto u = cast(uint)0xABCD - cast(uint)0xDCBA; // result type is uint, no  
checks for overflow
auto i = cast(int)0xABCD - cast(int)0xDCBA; // result type is int, no  
checks for overflow

auto e = cast(uint)0xABCD - cast(int)0xDCBA; // an error, can't substruct  
int from uint

// type ctors in action:
auto i = int(cast(int)0xABCD - cast(int)0xDCBA); // result type is int, an  
exception on overflow
auto u = int(cast(uint)0xABCD - cast(uint)0xDCBA); // same here for uint


Non-negative values

Just use int/long. Or some ranged type ([0..short.max], [0..int.max],  
[0..long.max]) could be used as well. A library type, perhaps. Let's call  
it nshort/nint/nlong. It should have the same set of operations as  
short/int/long but makes additional checks. Throws on under- and overflow.

int x = 42;
nint nx = x; // ok
nx = -x; // throws

nx = int.max; // ok
++nx; // throws

nx = 0;
--nx; // throws

nx = 0;
nint ny = 42;

nx = ny; // no checking is done

int y = ny; // no checking is done, either
short s = ny; // error, cast needed

short s = cast(short)ny; // never throws
short s = short(ny); // might throw