Implement as_ne_bytes() for integers and floats

[hch12907]

This is related to issue #64464.

I am pretty sure that these functions are actually const-ify-able, and technically as_bits() can also be implemented for floats, but I might need some comments on both.

[rust-highfive]

r? @Mark-Simulacrum

(rust_highfive has picked a reviewer for you, use r? to override)

[Mark-Simulacrum]

It seems like these should probably return arrays rather than slices. Those can then be coerced to a slice by the caller if needed, whereas the reverse requires a runtime check in general.

I am wondering if providing &mut [u8; N] access is warranted as well. It seems like a rare use case, but in the cases where you want it...

r? @LukasKalbertodt for unstable API signoff, though probably makes sense to wait for the conversion to arrays

[scottmcm]

Assuming that some form of rust-lang/rfcs#2981 will happen, does this need a distinct API?

[hch12907]

Modified as_ne_bytes to return arrays instead of slices.

I am wondering if providing &mut [u8; N] access is warranted as well.

I can add that, but I cannot really think of a use case for writing directly to an integer/a float by byte - usually [u8; N] or Vec<u8> is used when people want to write to a particular byte.

Assuming that some form of rust-lang/rfcs#2981 will happen, does this need a distinct API?

Interesting, I wasn't aware of that RFC. No, I don't think a distinct API will be needed once the RFC is merged, but I assume that it will be a while before the RFC is implemented, so it can be worthwhile to implement as_ne_bytes() first.

[roblabla]

Assuming that some form of rust-lang/rfcs#2981 will happen, does this need a distinct API?

Even if this happens, I still think having dedicated methods for some of these "basic" transmutation would be preferable from a UX standpoint. as_ne_bytes method on integers and floats is more discoverable and easier to understand than the generic mechanisms of the safe transmutation RFC. If/When that RFC is implemented, this method can be rewritten as a wrapper around safe transmutation to avoid the unsafe.

[HeroicKatora]

It seems like these should probably return arrays rather than slices.

If so then it seems useful to have a signature converting an array of numbers as well. (As in, either keep an array or add the slice-to-slice api). That would in particular make it possible to use the standard Read and Write interfaces with integers and floats, without another buffer layer or multiple io-calls.

fn as_ne_bytes(slice: &[Self]) -> &[u8];

[LukasKalbertodt]

Thanks for the PR!

I'm fine with merging these methods as unstable. Before stabilization we can reconsider if we actually need them or whether the safe transmute RFC is sufficient.

A few things:

• Please create a new dedicated tracking issue (or let me know if you prefer me to open it) and merge both feature names into num_as_ne_bytes (or so).
• The transmutes can be replaced by pointer casts (self as *const Self as *const [u8; N]). I don't know if this is less dangerous than transmute, but transmute docs mention it as an alternative that should be preferred.
• Not sure if it's worth first transmuting the floats into ints and then into the array. Why not transmute/cast them directly?

[bors]

☔ The latest upstream changes (presumably #76327) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

[hch12907]

The PR should be ready now.

[LukasKalbertodt]

Looks good to me!

[LukasKalbertodt]

@bors r+

[bors]

📌 Commit 3c582db has been approved by LukasKalbertodt

[bors]

⌛ Testing commit 3c582db with merge 0644cc1...

[bors]

☀️ Test successful - checks-actions, checks-azure
Approved by: LukasKalbertodt
Pushing 0644cc1 to master...