Treating the abusive unsigned syndrome

[Don]

Andrei Alexandrescu wrote:
> Denis Koroskin wrote:
>> On Wed, 26 Nov 2008 18:24:17 +0300, Andrei Alexandrescu 
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>
>>> Also consider:
>>>
>>> auto delta = a1.length - a2.length;
>>>
>>> What should the type of delta be? Well, it depends. In my scheme that 
>>> wouldn't even compile, which I think is a good thing; you must decide 
>>> whether prior information makes it an unsigned or a signed integral.
>>>
>>
>> Sure, it shouldn't compile. But explicit casting to either type won't 
>> help. Let's say you expect that a1.length > a2.length and thus expect 
>> a strictly positive result. Putting an explicit cast will not detect 
>> (but suppress) an error and give you an erroneous result silently.
> 
> But "silently" and "putting a cast" don't go together. It's the cast 
> that makes the erroneous result non-silent.
> 
> Besides, you don't need to cast. You can always use a function that does 
> the requisite checks. std.conv will have some of those, should any 
> change in the rules make it necessary.

I doubt that would be used in practice.

> By this I'm essentially replying Don's message in the bugs newsgroup: 
> nobody puts a gun to your head to cast.
> 
>> Putting an assert(a1.length > a2.length) might help, but the check 
>> will be unavailable unless code is compiled with asserts enabled.
> 
> Put an enforce(a1.length > a2.length) then.
> 
>> A better solution would be to write code as follows:
>>
>> auto delta = unsigned(a1.length - a2.length); // returns an unsigned 
>> value, throws on overflow (i.e., "2 - 4")
>> auto delta = signed(a1.length - a2.length); // returns result as a 
>> signed value. Throws on overflow (i.e., "int.min - 1")
>> auto delta = a1.length - a2.length; // won't compile
> 
> Amazingly this solution was discussed with these exact names! The signed 
> and unsigned functions can be implemented as libraries, but 
> unfortunately (or fortunately I guess) that means the bits32 and bits64 
> are available to all code.
> 
> One fear of mine is the reaction of throwing of hands in the air "how 
> many integral types are enough???". However, if we're to judge by the 
> addition of long long and a slew of typedefs to C99 and C++0x, the 
> answer is "plenty". I'd be interested in gaging how people feel about 
> adding two (bits64, bits32) or even four (bits64, bits32, bits16, and 
> bits8) types as basic types. They'd be bitbags with undecided sign ready 
> to be converted to their counterparts of decided sign.

Here I think we have a fundamental disagreement: what is an 'unsigned 
int'? There are two disparate ideas:

(A) You think that it is an approximation to a natural number, ie, a 
'positive int'.
(B) I think that it is a 'number with NO sign'; that is, the sign 
depends on context. It may, for example, be part of a larger number. 
Thus, I largely agree with the C behaviour -- once you have an unsigned 
in a calculation, it's up to the programmer to provide an interpretation.

Unfortunately, the two concepts are mashed together in C-family 
languages. (B) is the concept supported by the language typing rules, 
but usage of (A) is widespread in practice.

If we were going to introduce a slew of new types, I'd want them to be 
for 'positive int'/'natural int', 'positive byte', etc.

Natural int can always be implicitly converted to either int or uint, 
with perfect safety. No other conversions are possible without a cast.
Non-negative literals and manifest constants are naturals.

The rules are:
1. Anything involving unsigned is unsigned, (same as C).
2. Else if it contains an integer, it is an integer.
3. (Now we know all quantities are natural):
If it contains a subtraction, it is an integer [Probably allow 
subtraction of compile-time quantities to remain natural, if the values 
stay in range; flag an error if an overflow occurs].
4. Else it is a natural.


The reason I think literals and manifest constants are so important is 
that they are a significant fraction of the natural numbers in a program.

[Just before posting I've discovered that other people have posted some 
similar ideas].