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

[Matthias Bentrup via Digitalmars-d]

On Friday, 21 November 2014 at 15:36:02 UTC, Don wrote:
> 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.
>

So if i is a natint the expression i-- would change the type of 
variable i on the fly to int ?