Add methods for use cases that `align_to` does not cover

[oli-obk]

Proposal

Problem statement

The align_to slice method is only useful for optimizations that want to process all elements of the original slice, but has an optimized path for larger or more-aligned elements. The function may fall back to not producing a middle (aligned) slice and instead just return the original slice in the head or tail slice (for which, according to align_to's docs, an implementation must exist).

There are many users in the ecosystem that use it for guaranteed alignment, which, while working most of the time, is not guaranteed by the API.

Related discussion: https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/align_to.20and.20other.20APIs.20with.20surprising.20const.20behavior

Motivation, use-cases

When you have a slice to primitives (like integers), it is sometimes convenient to convert said slice to a smaller or larger primitive. Especially common are conversions to and from [u8].

Solution sketches

Add two new slice methods (plus their mut counterparts):

• aligned_subslice: Get a subslice where the first element is aligned to a given alignment and the size of the slice is a multiple of the alignment.
• transmute_elements:
  • Transmute the slice elements to another type.
  • If the target element type is smaller than the source element type, the returned slice will have multiple elements per element of the original slice.
  • Cannot be used to go to an element type with higher alignment requirements. Use aligned_subslice for that instead.

Alternatives:

We can also remove the fuzziness of the align_to method, but that would mean it could never be used in const eval.

Links and related work

• https://github.com/rust-lang/rust/pull/105296 implements this change

What happens now?

This issue is part of the libs-api team API change proposal process. Once this issue is filed the libs-api team will review open proposals in its weekly meeting. You should receive feedback within a week or two.

[the8472]

Under which circumstances does code just ignore the head and tail? If it's about getting overaligned memory, wouldn't it be better to put it in an allocation API?

[oli-obk]

Essentially yes, but I believe also for scratch space on the stack (getting a [u8; 15] and finding an 8-byte aligned subslice in there and producing a &u64 to it. The first 5 search results on github for uses of align_to are ignoring the head slice:

https://github.com/PsichiX/Oxygengine/blob/adef2107dee0cb6f5d816d5dec277479e801c5e7/engine/ha-renderer-debugger/src/system.rs#L245 https://github.com/twitter/ccommon/blob/f0f44568f22cde41794ba218cad592a424696af9/rust/ccommon-sys/src/metric.rs#L42 https://github.com/akhramov/knast/blob/8c9f5f481a467a22c7cc47f11a28fe52536f9950/common_lib/src/lib.rs#L3 https://github.com/slint-ui/slint/blob/24500fbf6b7cf0529b277c7bca73357d7a5e561f/examples/opengl_underlay/main.rs#L95

[the8472]

All those cases look like they go to the same or smaller alignment, so transmute_elements would work for that purpose.

aligned_subslice is about going to a higher alignment, I was asking about that case. Does anyone do that on memory they don't own? If not that maybe an allocation API would be better. Or an to_aligned::<T>() that asserts that there's no head and tail because one is slicing correctly into a prealigned buffer at the right offset and length.

[ChayimFriedman2]

Maybe we can guarantee that aligned_to() will always return the biggest possible middle slice, but only not during const eval?

[oli-obk]

Has seen no activity in 1 year, let's take it off the T-libs pile