GDC adds intrinsic support for core.checkedint

[tsbockman via Digitalmars-d]

On Wednesday, 1 July 2015 at 21:15:33 UTC, Robert burner Schadek 
wrote:
> On Tuesday, 30 June 2015 at 20:24:38 UTC, tsbockman wrote:
>>     4. Robert has suggested that a SafeInt type should disable 
>> bitwise operations like ~, &, |, ^, but I don't understand why.
>
> The name SafeInt and the missing bitwise operations go in 
> tandem.
> SafeInt is a math type, +-/*% nothing more. Whenever I saw 
> people beginning cleaver and use bitwise operations for math, 
> they failed. Me included.
>
> Thats why

That makes sense. However, I am still interested in knowing 
whether others generally share your view, or mine.

I, personally, find bitwise operations useful. Bitwise operators 
are not just for "clever" code; the use of `x << y` rather than 
`x * 2^^y` both ensures good code gen, and is clear and concise.

API-wise, there are a few different options:

1. Disable bitwise operations on `SafeInt`.

     Pros: Discourages the use of bug-prone optimization 
techniques.

     Cons: Code that actually has a good reason to use bitwise 
operators either ends up being rewritten in a 
slow/unnatural/bug-prone fashion using the approved operators, or 
it is written against `SafeInt.value` and is not only unchecked 
itself, but also disrupts the propagation of NaN states from 
earlier checked operations.

2. Include checked (NaN propagating) bitwise operations in 
`SafeInt`.

     Pros: Allows safe, efficient use of bitwise operations where 
appropriate.

     Cons: Allows abuse of bitwise operations to write inscrutible 
"clever" code.

3. Make checked bitwise operations optional according to an 
additional template parameter to `SafeInt`.

     Pros: Allows safe, efficient use of bitwise operations where 
appropriate. Where they are not needed, the programmer may 
request that the compiler block their abuse.

     Cons: Complicates the design and usage of `SafeInt`.

I now understand your motivation for banning the use of bitwise 
operations with `SafeInt`.

However, I really don't think removing them entirely from 
`SafeInt` is a good idea; it takes so little code to work around 
this restriction that people (me, for one) will just use them 
anyway.

Without checked versions in `SafeInt`, more code that converts 
between `SafeInt` and built-in integral types will be written. 
Unless we always throw an exception when unwrapping a NaN value, 
such code will tend to silently eat NaN states and hide bugs even 
in the preceding checked arithmetic.

More generally, all the bitwise operators except the shifts 
(`<<`, `>>`, and `>>>`) have very well-defined and predictable 
behaviour. Even the shifts are no more confusing to work with 
than the equivalent composites of `*` or `/` with `2^^`.

It doesn't really seem to fit the spirit of D to ban such 
well-behaved basic tools just because people sometimes try to use 
them for things they shouldn't. People write incorrect algorithms 
or forget to handle corner cases when working with the normal 
arithmetic operators all the time; should we ban them?