Change:
self.to_bits().to_ne_bytes() } <del> /// Return the memory representation of this floating point number as a byte array in /// native byte order. /// /// [`to_ne_bytes`] should be preferred over this whenever possible. /// /// [`to_ne_bytes`]: f32::to_ne_bytes /// /// # Examples /// /// ``` /// #![feature(num_as_ne_bytes)] /// let num = 12.5f32; /// let bytes = num.as_ne_bytes(); /// assert_eq!( ///     bytes, ///     if cfg!(target_endian = "big") { ///         &[0x41, 0x48, 0x00, 0x00] ///     } else { ///         &[0x00, 0x00, 0x48, 0x41] ///     } /// ); /// ``` #[unstable(feature = "num_as_ne_bytes", issue = "76976")] #[inline] pub fn as_ne_bytes(&self) -> &[u8; 4] { // SAFETY: `f32` is a plain old datatype so we can always transmute to it unsafe { &*(self as *const Self as *const _) } } </del> /// Create a floating point value from its representation as a byte array in big endian. /// /// # Examples

Discussion:
The feature gate for the issue is . Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [x] Implementation () [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev-
Ad discussed starting in I’m not convinced this feature carries its weight to be included in the standard library, given that also exists.
may be more useful.
How so? Trying to go beyond "I want to borrow because I want to borrow"
In a similar vein, I was curious if the opposite existed, converting from to : I do not have a specific usecase in mind. My thoughts were likewise around avoiding the copy (small as it may be).
Something kind of like that exists:  It returns because the byte slice might not be aligned properly for an , so it returns the unaligned parts separately. It's also unsafe because it can transmute to any type. A safe version for integers could be possible, but that won't solve the alignment problem.
A good point! The original case had a , which I neglected to show here. You get that "for free" if you store a and have something like the suggested .
Sorry for replying really late here (I accidentally unsubscribed from the issue.) but how should I proceed from here? Remove the function from std as per Simon's suggestion Add another function Though, the one does sound interesting to me although it is unrelated my original use case.
This feature would be useful to make this be a safe conversion. Currently this requires unsafe code. We use this type of abstraction in ; it would also be handy in some serialization-type libraries.
One other suggestion.

It would be useful if this method returned a type like (pseudo-code for a newtype that guarantees that the byte array is 4-byte aligned). This would allow for safe two-way <-conversion. In other words, returning is nice in that it remembers the length, but it throws away the alignment. It would be nice if we could also retain the alignment information.
Which "this" are you referring to? Why does not work for you?
I meant that allows the conversion from to to be safe. Right now it requires .
Also: in conjunction with , this feature would also enable safe conversion from to .
Regarding : I believe that would be out of scope for this feature? At least, I am not aware of any machinery in that allows one to say "the returned value is N-byte aligned", so doing that would require a new feature that mimics the crate in .
I think I'm with on this one. Given that this can't (portably) have and , I'm not sure it's worth having as a distinct thing, assuming that the Safe Transmute project lands -- as one of its top two use cases is offering native-endian views into everything where it's safe to do so, including and and such.
Agreed. I think it would be great to wait and see what the Safe Transmute project gives us here.
The use case is valid but a more general mechanism is direly needed here (something like this came up in Portable SIMD discussions).
Opened which removes this feature.