Make functions in this crate `const`?

[JSorngard]

Now that const_float_arithmetic has been stabilized, will the functions in this crate be made const where possible? Or is this not in scope due to MSRV policy?

[tgross35]

The stabilization definitely would make it possible for some of these functions to work in const contexts. However, I don't think that is an API guarantee we want to make because it would be a pretty significant limit on flexibility (anything that uses SIMD, assembly, or generic algorithms would no longer usable).

I think the better solution is to just move the math functions from std to core, and then make those const using the host machine's implementation. This is already planned but we do need to improve some things in this crate before it is possible (e.g. fix rounding errors, make sure our implementation is performant enough to ship).

[tgross35]

I am going to close this since I don't think we will make any changes in this crate's public API. I brought the topic of const float math up on Zulip since I don't think it has been discussed too much before https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/Const.20float.20math (feel free to drop by there if you have any interest working on it)

[JSorngard]

Makes sense. I might drop by there later to help work on this, could be fun!

[burrbull]

I'd wait for 1.83 (beta now): rust-lang/rust#129195

[kpreid]

I think the better solution is to just move the math functions from std to core, and then make those const using the host machine's implementation.

Note that the Zulip discussion didn’t particularly reach a conclusion in favor of this plan, and in particular RalfJ opined that it is likely unsound:

so... I think it is a hard constraint that all compile-time float support must be done via fully deterministic implementations that behave the same across all platforms

Also, applications may benefit from access to this same kind of determinism. For example, today I use libm not only for no_std compatibility, but also so that I can compute reproducible results. (Of course, future versions of libm may change algorithm and break those results, but dependency versions are controllable.)

Supporting const still might be declared infeasible for libm (as noted above about SIMD etc.); I just wanted to point out that this particular alternate plan seems like it is not going to happen.

[burrbull]

Supporting const still might be declared infeasible for libm (as noted above about SIMD etc.); I just wanted to point out that this particular alternate plan seems like it is not going to happen.

What you think about 2-level implementation?

• 1st level: constant naive fallible implementation.

pub const fn try_sin() -> Result<f32, Error> {};

• 2nd level: wrapper which can choose implementation (naive, intrinsic, SIMD, etc.) and fails on Error.

pub fn sin() -> f32 {}