Time to move std.experimental.checkedint to std.checkedint ?

tsbockman thomas.bockman at gmail.com
Sat Mar 27 07:42:27 UTC 2021


On Saturday, 27 March 2021 at 03:25:04 UTC, Walter Bright wrote:
> The reasons people don't care that much about integer overflow 
> are:
>
> 1. they are not the cause of enough problems to be that 
> concerning
>
> 2. 2's complement arithmetic fundamentally relies on it

That's an implementation detail. There is no need at either the 
software or the hardware level to make it the programmer's 
problem by default.

Main memory is addressed as one giant byte array, but we interact 
with it through better abstractions most of the time (the stack 
and the heap).

> 3. it's hard to have signed and unsigned integer types coexist 
> without overflows, and not having unsigned types leads to ugly 
> kludges to get them

Correctly mixing signed and unsigned integers is hard for 
programmers to consistently get right, but easy for the computer. 
That's why the default should be for the computer to do it.

> 4. fast integer arithmetic is fundamental to fast code,

I did benchmarking during the development of checkedint. With 
good inlining and optimization, even a library solution generally 
slows integer math code down by less than a factor of two. (I 
expect a language solution could do even better.)

This is significant, but nowhere near big enough to move the 
bottleneck in most code away from I/O, memory, floating-point, or 
integer math for which wrapping is semantically correct (like 
hashing or encryption). In those cases where integer math code 
really is the bottleneck, there are often just a few hot spots 
where the automatic checks in some inner loop need to be replaced 
with manual checks outside the loop.

> not a mere micro-optimization.

By "micro-optimization" I mean that it does not affect the 
asymptotic performance of algorithms, does not matter much 
outside of hot spots, and is unlikely to change where the hot 
spots are in the average program.

> Who wants an overflow check on every pointer increment?

As with bounds checks, most of the time the compiler should be 
able to prove the checks can be skipped, or move them outside the 
inner loop. The required logic is very similar.


More information about the Digitalmars-d mailing list