# Suggestion: FFastMath intrinsics in stable **URL:** \ **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:** 31
**Author:** ![tkaitchuck](https://avatars.discourse-cdn.com/v4/letter/t/eb8c5e/32.png) [@tkaitchuck](https://internals.rust-lang.org/u/tkaitchuck)\ **Post date:** [April 17, 2021, 4:37am UTC](https://internals.rust-lang.org/t/suggestion-ffastmath-intrinsics-in-stable/14447/31 "2021-04-17T04:37:50Z")
> [@scottmcm](#): > > I agree with [kornel's post above](https://internals.rust-lang.org/t/suggestion-ffastmath-intrinsics-in-stable/14447/20) on this. Anything affecting a scope is awkward because it's unclear how it should affect calls to other functions -- be that `.sum()`, `.sqrt()`, overloaded operators, ndarray, etc. This can be done in an unambiguous way. For example if the appropriate calls are added to the primitive types the annotation only affects which call is invoked when using operators. (IE the meaning of `+` or `*` is changed in that scope) This of course means the answer to "Does this affect `.sum()`, `.sqrt()` etc." is "No". On the surface it might seem like the lack of propagation to called methods is a downside. However I think it may be necessary regardless of the approach. It ought to be possible for a particular crate / method to control its own meaning. It is highly undesirable for an application to depend on a library, where the library has many tests to check its correctness, but these are circumvented because the application it is embedded into changes the meaning of multiplication inside of it. This pitfall is precisely why `--fast-math` has a bad reputation. Regardless of syntax, if the control is local, we can maintain consistency and testability and don't need to regard it as unsafe. --- _[View the full topic](https://internals.rust-lang.org/t/suggestion-ffastmath-intrinsics-in-stable/14447)._