Proposal: fixing the 'pure' floating point problem.

[Don]

Walter Bright wrote:
> While it's a good suggestion, I think there's a fundamental problem with 
> it. Suppose a function in the floatingpoint module calls foo() in a 
> non-floatingpoint module which calls std.math.sin(x). std.math.sin(x) is 
> marked as "pure" in a non-floatingpoint module. So, inside foo(), it is 
> assuming that sin(x) is pure and caches the value, while its caller is 
> manipulating the rounding mode and making repeated calls to foo() 
> expecting different answers.

That's true, but if you're in a floatingpoint module, and you call a 
non-floatingpoint module, it's your responsibility to make sure that the 
rounding mode is back to normal. You're saying that you don't care about 
the status flags. So it's your own fault if you get surprising results.

The primary use for adjusting the rounding mode is for things like 
implementing interval arithmetic. Thus, it's only ever used for small 
functions.