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
