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

[John Colvin via Digitalmars-d]

On Friday, 21 November 2014 at 16:12:19 UTC, Don wrote:
> 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.

I was under the impression that in D:

uint = { x mod 2^32 | x ∈ Z_0 }
int = { x - 2^31 | x ∈ uint }

which matches the hardware.