The Problem With DIPs

[Ola Fosheim Grøstad via Digitalmars-d]

On Wednesday, 15 June 2016 at 20:50:25 UTC, deadalnix wrote:
> Consider that there are many optimizations that rely on fp not 
> being predictable. For instance, fabs(x) can be transformed 
> into x | 0x80000000 if you don't care about NaN's sign (yes, 
> NaN are signed).

I guess that would be "-fabs(x)"? NaNs are signed, 
quiet/signalling and may carry an id. Floating point would truly 
benefit from a more constraint based typing system, but not sure 
how that would work out with D. (E.g. constraining a type to be 
non-Nan, non-Infinity, non-Zero etc subtype)

I am thinking that one should keep strict semantics and sloppy 
semantics separate in the type system. I am not a big fan of 
letting the compiler switches control it, so maybe float/double 
should work more like C/C++ or current D.

Then have other types for the strict semantics and allow direct 
bitmasking operations/simd. The overall solution could be 
restricted to a useful, but reproducible subset of 754-2008 
(avoiding trancendentals). Meaning, you would have to cast to 
double/float to get non-reproducible behaviour.

Then you can have implicit transition from strict->sloppy, but 
require explicit casting the other way.

For the strict type the rounding mode probably should be part of 
the type, enabling interval arithmetics and avoiding the "dynamic 
typing issues" of run-time rounding mode. Interval arithmetics is 
something that is hard to get right with the main C/C++ compilers.