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?
