ACP: slice::{split_,}{first,last}_chunk

[clarfonthey]

Proposal

This is an ACP for rust-lang/rust#95198, which I believe predates ACPs. Either that or I just didn't know about them at the time.

Problem statement

In some cases, it's valuable to convert between slices and arrays, and there's not really a good way to do this safely.

Motivation, use-cases

The current best API we have for this is the unstable as_chunks, which leads to the below being used fairly often:

slice.as_chunks::<N>().0[0]

Which just isn't as readable.

Solution sketches

The proposed solution:

impl [T] {
    pub const fn first_chunk<const N: usize>(&self) -> Option<&[T; N]>;
    pub const fn first_chunk_mut<const N: usize>(&mut self) -> Option<&mut [T; N]>;
    pub const fn last_chunk<const N: usize>(&self) -> Option<&[T; N]>;
    pub const fn last_chunk_mut<const N: usize>(&mut self) -> Option<&mut [T; N]>;
    pub const fn split_first_chunk<const N: usize>(&self) -> Option<(&[T; N], &[T])>;
    pub const fn split_first_chunk_mut<const N: usize>(&mut self) -> Option<(&mut [T; N], &mut [T])>;
    pub const fn split_last_chunk<const N: usize>(&self) -> Option<(&[T; N], &[T])>;
    pub const fn split_last_chunk_mut<const N: usize>(&mut self) -> Option<(&mut [T; N], &mut [T])>;
}

This borrows directly from the first/last APIs:

impl [T] {
    pub const fn first(&self) -> Option<&T>;
    pub const fn first_mut(&mut self) -> Option<&mut T>;
    pub const fn last(&self) -> Option<&T>;
    pub const fn last_mut(&mut self) -> Option<&mut T>;
    pub const fn split_first(&self) -> Option<(&T, &[T])>;
    pub const fn split_first_mut(&mut self) -> Option<(&mut T, &mut [T])>;
    pub const fn split_last(&self) -> Option<(&T, &[T])>;
    pub const fn split_last_mut(&mut self) -> Option<(&mut T, &mut [T])>;
}

Links and related work

The PR with the proposed solution: rust-lang/rust#95198
Discussion in the array_chunks tracking issue: rust-lang/rust#74985

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]

It's unfortunate that split_first already exists, otherwise I would have suggested naming it pop_first instead.

[clarfonthey]

Naming it pop_first would definitely be confusing since the Deref implementation on Vec would imply something actually being removed, when it's just splitting the slice.

[m-ou-se]

We briefly discussed this in the libs-api meeting just now, and we're not sure how much value this adds, since the existing array_chunks (etc.) seem to cover most (all?) of these.

We tend to be very cautious to add many more methods to very common slices like slices. Does any of the proposed functionality currently require unsafe or overly verbose code?

[m-ou-se]

An alternative might be to consider an alternative where this functionality is added to the ArrayChunks type.

[clarfonthey]

I'll have to get back to you on the iterator alternatives; I think they may cover it, but I haven't done a full sweep since I wrote this.

[cuviper]

We would need array_rchunks to cover last_chunk, or you can write slice.as_rchunks().1.last(). Split is harder though, to get the remainder and all other chunks in a single slice.

[clarfonthey]

Yeah, I would imagine that iterators cover most of the cases, though. Not necessarily ergonomic for the split, but I personally don't know how often people would use it.

My main issue with as_chunks is that, while it works, having to index into a slice inside a tuple makes the code look kind of cryptic. While it's not unclear, it definitely has a cognitive complexity to it-- I know that .0[0] means "the first of the first," but it takes a moment to fully realise what that means.

[shepmaster]

having to index into a slice inside a tuple

I expect most times I’ll destructure the tuple:

let (chunks, tail) = foo.as_chunks();

probably often with an assert!(tail.is_empty()).

[m-ou-se]

We discussed this again in a libs meeting, and we seem to feel more positive about these methods now. Please go ahead and open a new tracking issue for these, to add these as unstable. Thanks!