GDC adds intrinsic support for core.checkedint

[Dominikus Dittes Scherkl via Digitalmars-d]

On Tuesday, 30 June 2015 at 20:24:38 UTC, tsbockman wrote:
>     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?
I would prefer SafeInt!T

>
>     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;
Yup. For my personal taste, safe unsigned int is rather useless
- if I use unsigned, I'm almost always about to do something 
including bit-operations for which overflow check is distracting 
at the best.

For the signed types I use the abbreviations with "s" in front, 
and 16bit
I still call a word, so the list beeing:

sbyte, sword, sint, slong (, scent)

I love to swing my sword!

>        (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?

Yes! I would always recommend to use those instead of the buildin 
signed types, because signed types should be the first thing 
everybody uses and should protect you from shooting in your foot 
the best - they will be heavily used in D-scripts, where speed is 
not the main goal and not used for bit-operations anyway.

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

Maybe, but if you print out the end result and see a "NaN", you 
are immediately sure there has happened an overflow somewhere and 
searching the bug will be very easy. If you want to throw an 
exception, do it yourself!
I don't want a safe type to do it for me - it destroys the reason 
for having a NaN value.

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

I do - for signed types they make very little sence and are 
likely to destroy the bit pattern - so either you need to check 
if the pattern becomes NaN or was NaN from the start, or you 
allow that those operations create a number from a NaN input - 
both very bad.
And as already mentioned: I will never use unsigned safe int, 
because I need the bit operations for unsigned types, and they 
ought to be fast!
Because I use unsigned types only if I plan to do something 
outside standard math and than I have to do all checks myself 
anyway.
>
>        It seems highly desirable to me to have NaN values 
> propagate sensibly through all standard integer "math"
Yes!
especially for ^^

> not only the operators, but also things like core.bitop and the 
> integer operations in std.math.
May be, but I don't think using them for signed types make much 
sense in the first place.

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

sounds nice, but I think it's not an easy goal.

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

I'm currently taking a deeper look, get my answer later!