Tracking Issue for `#![feature(const_float_methods)]`

[eduardosm]

Feature gate: #![feature(const_float_methods)]

This is a tracking issue for making const some methods of floating point types.

Public API

// in `core`
impl <float> {
    pub const fn recip(self) -> Self;
    pub const fn to_degrees(self) -> Self;
    pub const fn to_radians(self) -> Self;
    pub const fn max(self, other: Self) -> Self;
    pub const fn min(self, other: Self) -> Self;
    pub const fn clamp(self, min: Self, max: Self) -> Self;
    pub const fn abs(self) -> Self;
    pub const fn signum(self) -> Self;
    pub const fn copysign(self, sign: Self) -> Self;
}

Steps / History

• Implementation: Make some float methods unstable const fn #130568
• Final comment period (FCP)¹: Tracking Issue for #![feature(const_float_methods)] #130843 (comment)
• Stabilization PR: Stabilize const_float_methods #133389

Unresolved Questions

• None yet.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[RalfJung]

@rust-lang/libs-api @rust-lang/wg-const-eval these all have fairly simple implementations, fully in libcore, without relying on any complicated libm or runtime support. Most have been stable since 1.0, the most recent one is clamp which is stable since 1.50. So I think we can proceed with const-stabilizing them.

@rust-lang/lang @rust-lang/wg-const-eval this does involve exposing some intrinsics via stable const fn: abs and copysign. Those are both non-arithmetic operations, which means they are defined directly on the bit representation of floats, and could easily be implemented with from_bits/to_bits. Their const-eval interpretation has been used in Miri for years.