GDC adds intrinsic support for core.checkedint

[tsbockman via Digitalmars-d]

On Tuesday, 30 June 2015 at 18:25:14 UTC, Iain Buclaw wrote:
> Hi,
>
> GDC now recognizes all functions in core.checkedint as 
> intrinsics.  May you all enjoy using inlined, hardware 
> leveraged, overflow-checking integer operations.
>
> https://github.com/D-Programming-GDC/GDC/pull/110
>
> I say 'you all', but what I really mean is 'bearophile'. :-)
>
> Regards
> Iain.

core.checkedint is not very nice to work with directly, so Robert 
burner Schadek and I have been working on a wrapper struct for 
Phobos.

     Robert's version: 
https://github.com/D-Programming-Language/phobos/pull/3389
     My version:       https://github.com/tsbockman/CheckedInt

     Some comparative benchmarks (note: these predate Iain's 
update to GDC):
https://github.com/D-Programming-Language/phobos/pull/3389#issuecomment-115997507

I don't think either of our versions is ready to be pulled - for 
one thing, mine has no documentation yet. However, we could use 
some feedback from anyone interested in making use of checked 
integer arithmetic:

     1. What name do you prefer? SafeInt!T? CheckedInt!T? 
Something else?

     2. Regardless of which name is selected, it will still be 
rather verbose. I myself intend to use aliases like these to 
streamline things:

alias cint = CheckedInt!int;
alias cuint = CheckedInt!uint;
// etc...

static if(debug) {
   alias dint = CheckedInt!int;
   alias duint = CheckedInt!uint;
   // etc...
} else {
   alias dint = int;
   alias duint = uint;
   // etc...
}

        (These aliases could easily be placed in a separate 
module, or in a mixin template, to prevent namespace pollution 
when they aren't wanted.)

        Would anyone else like to see aliases like these included 
in Phobos?

     3. I know D is on a big @nogc nothrow kick right now, but 
this seems like something where exceptions could be really 
useful. It would be easy to forget to manually check .isNaN.

        I think a template option should be included to throw an 
exception when attempting to unwrap a NaN value. The API I have 
in mind would still allow unchecked unwrapping when explicitly 
requested, and the performance hit from the extra branches should 
be minimal.

        The disadvantage of throwing when unwrapping is that the 
exception might be thrown much later than the NaN value was 
actually generated. The alternative would be to throw immediately 
when a NaN is generated. However, this would be substantially 
slower in at least some cases.

        Thoughts?

     4. Robert has suggested that a SafeInt type should disable 
bitwise operations like ~, &, |, ^, but I don't understand why.

        It seems highly desirable to me to have NaN values 
propagate sensibly through all standard integer "math" - not only 
the operators, but also things like core.bitop and the integer 
operations in std.math.

        Ideally, I would like to have a sufficiently complete set 
of CheckedInt!T-aware math operations, that the implicit 
conversion to T could be removed so that the compiler would 
remind people to check isNaN before passing the wrapped value to 
non-CheckedInt!T-aware functions.

        (I'm not sure it will really make sense to go that far, 
though, since this scheme would still add syntactic friction to 
things like indexing an array with a CheckedInt.)

        What features do you want?

     5. For anyone who cares to take a look at our 
work-in-progress code, which version looks more promising to you 
at this point? Robert's, or mine?