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

[Walter Bright via Digitalmars-d]

On 11/21/2014 7:36 AM, Don wrote:
> On Friday, 21 November 2014 at 04:53:38 UTC, Walter Bright wrote:
>> 0 crossing bugs tend to show up much sooner, and often immediately.
>
>
> You're missing the point here. The problem is that people are using 'uint' as if
> it were a positive integer type.
>
> 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  !!!
>
> This would of course overflow if the result is too big to fit in an int. But the
> type would be correct.  1 - 2 == -1.
>
> But
>
> typeof (uint - uint ) == uint.
>
> The bit pattern is identical to the other case. But the type is wrong.
>
> It is for this reason that uint is not appropriate as a model for positive
> integers. Having warnings about mixing int and uint operations in relational
> operators is a bit misleading, because mixing signed and unsigned is not usually
> the real problem. Instead, those warnings a symptom of a type system mistake.
>
> You are quite right in saying that with a signed length, overflows can still
> occur. But, those are in principle detectable. The compiler could add runtime
> overflow checks for them, for example. But the situation for unsigned is not
> fixable, because it is a problem with the type system.
>
>
> By making .length unsigned, we are telling people that if .length is
> used in a subtraction expression, the type will be wrong.
>
> It is the incorrect use of the type system that is the underlying problem.

I believe I do understand the problem. As a practical matter, overflow checks 
are not going to be added for performance reasons. Also, in principle, uint-uint 
can generate a runtime check for underflow (i.e. the carry flag).