Wishlist for D

tsbockman via Digitalmars-d digitalmars-d at puremagic.com
Tue Dec 15 23:41:45 PST 2015


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...


More information about the Digitalmars-d mailing list