Tracking Issue for slice_as_array

[bjoernager]

Feature gate: #![feature(slice_as_array)]

This is a tracking issue for adding conversion functions from slices to arrays.

Public API

impl<T> [T] {
    pub const fn as_array<const N: usize>(&self) -> Option<&[T; N]>;

    pub const fn as_mut_array<const N: usize>(&mut self) -> Option<&mut [T; N]>;
}

impl<T> *const [T] {
    pub const fn as_array<const N: usize>(self) -> Option<*const [T; N]>;
}

impl<T> *mut [T] {
    pub const fn as_mut_array<const N: usize>(self) -> Option<*mut [T; N]>;
}

// alloc::boxed

impl<T> Box<[T]> {
    pub fn into_array<const N: usize>(self) -> Option<Box<[T; N]>>;
}

// alloc::rc

impl<T> Rc<[T]> {
    pub fn into_array<const N: usize>(self) -> Option<Rc<[T; N]>>;
}

// alloc::sync

impl<T> Arc<[T]> {
    pub fn into_array<const N: usize>(self) -> Option<Arc<[T; N]>>;
}

Steps / History

• API change proposal (ACP): #496
• Implementation for [T], *const [T], and *mut [T]: Add as_array and as_mut_array conversion methods to slices. #133512
• Fix docs for <[T]>::as_array: Fix docs for <[T]>::as_array. #133743
• Implementation for Box<[T]>, Rc<[T]>, and Arc<[T]>: Add into_array conversion destructors for Box, Rc, and Arc. #134379
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• const-compatible for the non-primitive types?
• Option or Result for the owning conversions?
• Implementations for Mutex and RwLock?
• Vec::into_boxed_array?
• str::as_bytes_array and String::into_boxed_bytes_array?

[bjoernager]

@RustyYato suggests the following signature for the alloc-typed slices:

pub fn into_array<const N: usize>(self) -> Result<Self<[T; N]>, Self<[T]>>;

to prevent accidental leaks if conversion fails. Would this be preferred as-is or would a new error type (e.g. SliceIntoArrayError) have to be defined?

[programmerjake]

well, if you use Rc::<dyn Any>::downcast as precedence, just returning Result<Rc<[T; N]>, Rc<[T]>> (and likewise for other owning types) should be good imo

[bjoernager]

I am aware that they mostly do not specialise any methods, but could (and should) we extend this to also include Mutex and RwLock?

[hanna-kruppe]

Do any of the unresolved questions apply to the basic slice methods? If not, I'd like to see them stabilized on their own. While they're somewhat redundant with the TryFrom impls if you don't need const support¹ they have enough advantages to justify their existence IMO:

• The more specific names makes it easier to understand what's happening without lots of type annotations, both that any particular call is just a slice->array cast and whether it's producing &[T; N], &mut [T; N], or [T; N].
• For the same reason, type inference and diagnostics for as_array[_mut] should be more reliable than the TryFrom impls. I occasionally write a slice->array .try_into() call and then have to rewrite it to add type annotations until it either does what I want or I get a diagnostic pointing out the actual reason why the TryFrom impl I wanted can't be applied.
• When spelling out the array length is necessary or desirable, as_array[_mut] make it easy to turbofish while keeping method call sugar (in particular auto-ref). Much nicer than having to switch from e.g. foo().try_into() to <&mut [_; N]>::try_from(&mut foo()).

Footnotes

1. The const compatibility difference is hopefully only temporary. If you do want this operation in const today, it's not too difficult to implement on top of first_chunk[_mut]. But often you can't use first_chunk directly without risking bugs from the slice being longer than expected. ↩

[bjoernager]

I guess the fact that you call them as_array_mut is an indication that naming is still an open topic...

That name was the initial suggestion but is not what has been implemented.

I think that the current choice is the "correct" choice (keeping in mind <[T; N]>::as_mut_slice). But we also have str::as_bytes_mut, so I am not completely certain as to how the naming convention is other than an idea.

But disregarding this, there doesn't seem to be any blockers for the primitive, non-str slice types.

[hanna-kruppe]

I guess there is a source for the as_mut_foo convention:

If the mut qualifier in the name of a conversion method constitutes part of the return type, it should appear as it would appear in the type. For example Vec::as_mut_slice returns a mut slice; it does what it says. This name is preferred over as_slice_mut.

I always forget about this because the "_mut as suffix" style is so overwhelmingly common. But it seems this guidance is applied somewhat consistently if you interpret it very narrowly as referring to the canonical name of the return type. So it probably doesn't apply to as_bytes_mut since &mut [u8] isn't necessarily pronounced "mut bytes". If the scope of this convention is really that narrow, then it may not apply to as_{mut_array,array_mut} returning Option<&mut [T; N]> either (glossing both over the reference and the Option seems like a stretch).

But I don't care either way, rust-analyzer is decently good at papering over such small naming differences.