Tracking issue for #![feature(const_float_bits_conv)]

[ecstatic-morse]

Tracking issue for the #![feature(const_float_bits_conv)] feature gate, which makes the following methods on f32 and f64 const fn:

• formerly #![feature(float_bits_conv)]
  • to_bits
  • from_bits
• formerly #![feature(float_to_from_bytes)]
  • to_bytes_be
  • to_bytes_le
  • to_bytes_ne
  • from_bytes_be
  • from_bytes_le
  • from_bytes_ne

These require transmute within a const fn to stabilize, and–unlike the recently stabilized #![feature(const_int_conversion)]–do not have a const-stable alternate implementation. Nevertheless, these may be useful for nightly users.

Stabilization is blocked on #57241.

[lebensterben]

Is there anyway to hard-code this without nightly?
I've a real world use case, I need to define
pub const NA_REAL: f64 = f64::from_le_bytes([0xa2, 0x07, 0x00, 0x00, 0x00, 0x00, 0xf0, 0x7f]);
which is the NA (not NaN) value used in R.

[ecstatic-morse]

transmute is stable in constants and statics (but not in const fn) as of 1.46.

[lebensterben]

pub const NA_REAL: f64 = unsafe {
    std::mem::transmute(u64::from_le_bytes([
        0xa2, 0x07, 0x00, 0x00, 0x00, 0x00, 0xf0, 0x7f,
    ]))
};

This works for me now.

[bstrie]

Stabilization is blocked on #57241.

Does that issue need to be a blocker for this? The functions in question aren't doing arithmetic on floats, they're just casting bit representations. AIUI while float arithmetic might be nonportable, bit representations are well-specified, yes?

[bstrie]

Actually, I take that back after looking at #73288 . from_bits(foo).to_bits() isn't even guaranteed to round-trip properly...

[thomcc]

Is there any reason from_bits couldn't be stabilized on its own (without to_bits)? I think to_bits is the problematic one (or at least, it's the one with open questions).

It might not seem useful to provide just from_bits (and not to_bits) to const fn, but here are two use cases:

1. Parsing floats at compile time, either from env!/option_env! or user provided string literals (e.g. you could imagine a version of that hex float crate that use const fn instead of proc macros).
2. A software floating point implementation that works in const fn (admittedly, as a way to hack around the current lack of support).

The 2nd is what I was poking around with, when I realized that I can't actually turn the result into a user-friendly f32/f64 (instead I have to give them a u32/u64, which needs to be from_bitsed outside of const).

[workingjubilee]

per @burrbull in #57241 (comment)
"const fn transmute is already stabilized"

This allows routing around these using unsafe const code. I think that the question now is whether we want to stabilize the safe methods or to instead fix the bugs that can cause unconst behavior (and thus, continue to make people unsafely assert that they believe the result will be const or, in effect, that it will not cause problems) and then stabilize them.