Suggestion: FFastMath intrinsics in stable

I think the approach of "make all operations in this module/package/crate fast" is just colored by the precedent in C where a global -ffast-math is all you can have. It's not a good design.

It's super ambiguous in its meaning. Does it affect iter().sum()? sum is defined in a different crate! If it doesn't affect code defined elsewhere, then it basically won't work at all, because all float std::ops::* are defined in std. Does it simply affect only code generated during compilation of the crate, like ffast-math? Now monomorphisation, inlining decisions and LTO will affect code's semantics. Or does it affect meaning of all operations in all function calls, recursively? That's going to be hard to compile, and will affect code in functions that may have never been written with relaxed precision in mind.

11 Likes