# Suggestion: FFastMath intrinsics in stable

**URL:** <https://internals.rust-lang.org/t/suggestion-ffastmath-intrinsics-in-stable/14447>\
**Category:** libs\
**Created:** [April 8, 2021, 5:07pm UTC](https://internals.rust-lang.org/t/suggestion-ffastmath-intrinsics-in-stable/14447 "2021-04-08T17:07:33Z")\
**Posts on this page:** 1\
**Showing post:** 20

<div class="post-metadata">

**Author:** ![kornel](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/kornel/32/2711_2.png) [@kornel](https://internals.rust-lang.org/u/kornel)\
**Post date:** [April 11, 2021, 6:38pm UTC](https://internals.rust-lang.org/t/suggestion-ffastmath-intrinsics-in-stable/14447/20 "2021-04-11T18:38:47Z")

</div>

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.

---

_[View the full topic](https://internals.rust-lang.org/t/suggestion-ffastmath-intrinsics-in-stable/14447)._