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

[Walter Bright via Digitalmars-d]

On 11/24/2014 2:20 AM, Don wrote:
>> I believe I do understand the problem. As a practical matter, overflow checks
>> are not going to be added for performance reasons.
>
> The performance overhead would be practically zero. All we would need to do, is
> restrict array slices such that the length cannot exceed ssize_t.max.
>
> This can only happen in the case where the element type has a size of 1, and
> only in the case of slicing a pointer, concatenation, and memory allocation.

(length1 + length2) / 2


> In exchange, 99% of uses of unsigned would disappear from D code, and with it, a
> whole category of bugs.

You're not proposing changing size_t, so I believe this statement is incorrect.


>> Also, in principle, uint-uint can generate a runtime check for underflow (i.e.
>> the carry flag).
>
> No it cannot. The compiler does not have enough information to know if the value
> is intended to be positive integer, or an unsigned. That information is lost
> from the type system.
>
> Eg from C, wrapping of an unsigned type is not an error. It is perfectly defined
> behaviour. With signed types, it's undefined behaviour.

I know it's not an error. It can be defined to be an error, and the compiler can 
insert a runtime check. (I'm not proposing this, just saying it can be done.)


> To make this clear: I am not proposing that size_t should be changed.
> I am proposing that for .length returns a signed type, that for array slices is
> guaranteed to never be negative.

There'll be mass confusion if .length is not the same type as .sizeof