Proposal: fixing the 'pure' floating point problem.

[Daniel Keep]

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.

I thought the behaviour was that if you call a function in a
non-floatingpoint module, then that means the rounding mode is fixed at
the "default" and you can't externally change that.

  -- Daniel