On Wednesday, 16 December 2015 at 07:07:09 UTC, Charles Hixson
wrote:
It wouldn't need to be a breaking change if checked integer
were a separate type series, as the unsigned series is. The
types could be called "cint" etc. I expect that they would
incur significant overhead, as I don't think there is hardware
support for checked integers, and as such the current types
would need to be maintained.
There is hardware support for checked integers, actually. Even
the library type that Robert Schadek and I have been working on
will be able to at least partially leverage that support, through
the intrinsics in `core.checkedint`.
Still, there is always going to be some runtime overhead
associated with checked integers: at a minimum, including a code
path to explicitly handle integer math errors increases programs'
instruction count significantly.
Compiler support would allow the possibility of automatically
eliding redundant checks. More importantly, it would also make
compilation of code using lots of checked integers much faster,
as getting good performance and generic code compatibility with a
library checked integer requires templated function calls
everywhere, which must all be inlined.
As to it being a non-breaking change: the issue is that almost
all existing usage of `int`, should really be `cint`. Even if you
update your own code to use `cint`, interacting correctly with
APIs which erroneously use `int` gets awkward, assuming you want
to actually benefit from the improved safety of `cint`.
However, updating a public API to use `cint` is a breaking change
for both performance and type safety reasons.
Any such code updates would also have to be reviewed and tested
thoroughly, because while switching to `cint` would *almost*
always be a good thing, people do occasionally intentionally make
use of the wrapping nature of unchecked integers - and even of
the wonkiness of mixed signed/unsigned math. Since there is no
standard way currently of marking such cases, only a real person,
familiar with the code base, could update it - no (safe)
automated updates is possible.
Overall, it's probably not worth the additional work and risk of
adding support directly to the compiler, unless it's going to
become the default (as it should have been from the beginning).
Hence, D3...
