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.
- Proposal: fixing the 'pure' floating point problem. Don
- Re: Proposal: fixing the 'pure' floating point proble... Denis Koroskin
- Counter-proposal: Syntax for FP Attributes on blocks ... Joel C. Salomon
- Re: Proposal: fixing the 'pure' floating point proble... Walter Bright
- Re: Proposal: fixing the 'pure' floating point pr... Daniel Keep
- Re: Proposal: fixing the 'pure' floating point pr... Jason House
- Re: Proposal: fixing the 'pure' floating poin... Walter Bright
- Re: Proposal: fixing the 'pure' floating point pr... Don
- Re: Proposal: fixing the 'pure' floating poin... Walter Bright