'int' is enough for 'length' to migrate code from x86 to x64

[Don via Digitalmars-d]

On Friday, 21 November 2014 at 15:50:05 UTC, H. S. Teoh via 
Digitalmars-d wrote:
> On Fri, Nov 21, 2014 at 03:36:01PM +0000, Don via Digitalmars-d 
> wrote:
> [...]
>> Suppose  D had a type 'natint', which could hold natural 
>> numbers in
>> the range 0..uint.max.  Sounds like 'uint', right? People make 
>> the
>> mistake of thinking that is what uint is. But it is not.
>> 
>> How would natint behave, in the type system?
>> 
>> typeof (natint - natint)  ==  int     NOT natint  !!!
>
> Wrong. (uint.max - 0) == uint.max, which is of type uint.


It is not uint.max. It is natint.max. And yes, that's an overflow 
condition.

Exactly the same as when you do int.max + int.max.

> If you
> interpret it as int, you get a negative number, which is wrong. 
> So your
> proposal breaks uint in even worse ways, in that now 
> subtracting a
> smaller number from a larger number may overflow, whereas it 
> wouldn't
> before. So that fixes nothing, you're just shifting the problem
> somewhere else.
>
>
> T

This is not a proposal!!!! I am just illustrating the difference 
between what people *think* uint does, vs what it actually does.

The type that I think would be useful, would be a number in the 
range 0..int.max.
It has no risk of underflow.

To put it another way:

natural numbers are a subset of mathematical integers.
   (the range 0..infinity)

signed types are a subset of mathematical integers
   (the range -int.max .. int.max).

unsigned types are not a subset of mathematical integers.

They do not just have a restricted range. They have different 
semantics.


The question of what happens when a range is exceeded, is a 
different question.