Tracking Issue for num_as_ne_bytes feature

[hch12907]

The feature gate for the issue is #![feature(num_as_ne_bytes)].

pub mod core {
    pub mod f64 {
        impl f64 {
            pub fn as_ne_bytes(&self) -> &[u8; 8] {}
        }
    }

    pub mod f32 {
        impl f32 {
            pub fn as_ne_bytes(&self) -> &[u8; 4] {}
        }
    }
}

About tracking issues

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.

Steps

• Implementation (Implement as_ne_bytes() for integers and floats #76610)
• Adjust documentation (see instructions on rustc-dev-guide)
• Stabilization PR (see instructions on rustc-dev-guide)

[SimonSapin]

Ad discussed starting in #64464 (comment) I’m not convinced this feature carries its weight to be included in the standard library, given that to_ne_bytes also exists.

[mbartlett21]

as_ne_bytes_mut may be more useful.

[SimonSapin]

How so? Trying to go beyond "I want to borrow because I want to borrow"

[shepmaster]

In a similar vein, I was curious if the opposite existed, converting from &(mut) [u8; 4] to &(mut) u32:

let mut a = [1, 2, 3, 4];
let v: &mut u32 = u32::from_ne_bytes_mut(&mut a);
// Then potentially used with
let x = AtomicU32::from_mut(v);

I do not have a specific usecase in mind. My thoughts were likewise around avoiding the copy (small as it may be).

[m-ou-se]

@shepmaster Something kind of like that exists: [u8]::align_to::<u32>

It returns (&[u8], &[u32], &[u8]) because the byte slice might not be aligned properly for an u32, 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.

[shepmaster]

A good point! The original case had a repr(align), which I neglected to show here. You get that "for free" if you store a u32 and have something like the suggested as_ne_bytes_mut.

[hch12907]

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 as_ne_bytes_mut

Though, the AtomicU* one does sound interesting to me although it is unrelated my original use case.

[sffc]

This feature would be useful to make this be a safe conversion. Currently this requires unsafe code. We use this type of abstraction in TinyStr; it would also be handy in some serialization-type libraries.

[sffc]

One other suggestion. It would be useful if this method returned a type like Aligned<[u8; 4], 4> (pseudo-code for a newtype that guarantees that the byte array is 4-byte aligned). This would allow for safe two-way &u32 <-> &Aligned<[u8; 4], 4> conversion.

In other words, returning &[u8; 4] 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.

[SimonSapin]

to make this be a safe conversion

Which "this" are you referring to? Why does to_ne_bytes not work for you?

[sffc]

to make this be a safe conversion

Which "this" are you referring to? Why does to_ne_bytes not work for you?

I meant that as_ne_bytes() allows the conversion from &u32 to &[u8] to be safe. Right now it requires unsafe.

[sffc]

Also: in conjunction with #74985 (comment), this feature would also enable safe conversion from &[u32] to &[u8].

[hch12907]

Regarding Aligned<[u8; 4], 4>: I believe that would be out of scope for this feature?

At least, I am not aware of any machinery in std that allows one to say "the returned value is N-byte aligned", so doing that would require a new feature that mimics the aligned crate in std.

[scottmcm]

I think I'm with #76976 (comment) on this one. Given that this can't (portably) have .as_le_bytes() and .as_be_bytes(), 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 &[u8] native-endian views into everything where it's safe to do so, including f32 and u64 and such.

[BurntSushi]

@scottmcm Agreed. I think it would be great to wait and see what the Safe Transmute project gives us here.

[workingjubilee]

The use case is valid but a more general mechanism is direly needed here (something like this came up in Portable SIMD discussions).

[hch12907]

Opened #85679 which removes this feature.