Floating point rounding modes: we should restrict them slightly

[Don]

Walter Bright wrote:
> bearophile wrote:
>> An important purpose of a not bug-prone language is remove as many
>> undefined situations as possible.
> 
> That's right.
> 
>> If you add that to D2 specs, can
>> the compiler catch at compile time all cases of violations to that
>> rule?
> 
> Unlikely. But that has to be weighed against the former behavior being 
> defined in a useless way.

We could get close, I think. We could catch all violations in SafeD. 
Disallow calling core.stdc.fenv functions from inside SafeD modules, and 
provide an RAII object in std.math for changing the rounding mode.

Actually there's probably a few other C functions we want to prohibit in 
SafeD -- the infamous string functions, for example.

I think the goal should be try to remove undefined behaviour from SafeD.
Long term goal: "If a program uses no system modules other than those 
provided in the standard library, it should not be exposed to undefined 
behaviour." ?

>> D has something for the actions that must be done before the function
>> exits, the scope(exit). Can something like that be used to
>> automatically avoid undefined rounding situations?
> 
> Using an RAII object to do it might be better.

I agree. I'd like to do something similar with the floating point 
exception state, too. Haven't worked out the details yet.