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

[Don via Digitalmars-d]

On Friday, 21 November 2014 at 04:53:38 UTC, Walter Bright wrote:
> On 11/20/2014 7:11 PM, Walter Bright wrote:
>> On 11/20/2014 3:25 PM, bearophile wrote:
>>> Walter Bright:
>>>
>>>> If that is changed to a signed type, then you'll have a 
>>>> same-only-different
>>>> set of subtle bugs,
>>>
>>> This is possible. Can you show some of the bugs, we can 
>>> discuss them, and see if
>>> they are actually worse than the current situation.
>>
>> All you're doing is trading 0 crossing for 0x7FFFFFFF crossing 
>> issues, and
>> pretending the problems have gone away.
>
> BTW, granted the 0x7FFFFFFF problems exhibit the bugs less 
> often, but paradoxically this can make the bug worse, because 
> then it only gets found much, much later in supposedly tested & 
> robust code.
>
> 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.