On Wednesday, 19 November 2014 at 13:47:31 UTC, ketmar via
Digitalmars-d wrote:
On Wed, 19 Nov 2014 13:33:21 +0000
Don via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
No. Signed types do not *wrap*. They *overflow* if their range
is exceeded.
same for unsigned ints.
This is not the same thing. Overflow is always an error.
And the compiler could insert checks to detect this.
and for unsigned ints. i want compilers to has special code for
this.
something like `checkedInt(...)`. and this must be built-in,
'cause
checking carry flag is cheap, but can be done only on "machine"
level.
I don't know what you mean. For unsigned ints, carry is not an
error. That's the whole point of unsigned!
That's not possible for unsigned types. With an unsigned type,
wrapping is part of the semantics.
see above.
Moreover, hitting an overflow with a signed type is an
exceptional situation. Wrapping with an unsigned type is
entirely normal, and happens with things like 2u - 1u.
having results of unsigned int wrapping defined doesn't mean
that it's
"normal". it's just *defined*, so you can check for it without
triggering UB.
IMHO the correct solution is to say that the length of a slice
cannot exceed half of the memory space, otherwise a runtime
error will occur. And then make size_t a positive integer.
but why? maybe 1/3 of address space fits better? or 256 bytes,
to
really avoid "overflows" and "wrapping"?
No. The point is to get correct semantics. Unsigned types do not
have the correct semantics. Signed types do.
Then let typeof(size_t - size_t) == int, instead of uint. All
other operations stay as size_t.
check and cast. you can check length and then safely cast it to
int, no
probs.
This is the job of the compiler, not the programmer. The compiler
should do this at all possible places where a slice could exceed
the int.max / long.max. That's cheap because there are hardly any
places it could happen (for example, for array slices it can only
happen with 1-byte types).
---
Almost everybody seems to think that unsigned means positive. It
does not.
---
