Tracking Issue for split_array

[jethrogb]

View all comments

Feature gate: #![feature(split_array)]

This is a tracking issue for splitting slices and arrays into constant-length arrays.

Public API

impl<T, const N: usize> [T; N] {
    pub fn split_array_ref<const M: usize>(&self) -> (&[T; M], &[T]);
    pub fn split_array_mut<const M: usize>(&mut self) -> (&mut [T; M], &mut [T]);

    pub fn rsplit_array_ref<const M: usize>(&self) -> (&[T], &[T; M]);
    pub fn rsplit_array_mut<const M: usize>(&mut self) -> (&mut [T], &mut [T; M]);
}

Similar functions for slices have already been stabilized as:

impl [T] {
    pub const fn split_first_chunk<const N: usize>(&self) -> Option<(&[T; N], &[T])>;
    pub 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], &[T; N])>;
    pub fn split_last_chunk_mut<const N: usize>(&mut self) -> Option<(&mut [T], &mut [T; N])>;
}

See #111774

Unresolved Questions

• Naming, see Implement split_array and split_array_mut #83233 (review)
• Array functions should return [T; N - M], like so:

impl<T, const N: usize> [T; N] {
    pub fn split_array<const M: usize>(self) -> ([T; M], [T; N - M]);
    pub fn split_array_ref<const M: usize>(&self) -> (&[T; M], &[T; N - M]);
    pub fn split_array_mut<const M: usize>(&mut self) -> (&mut [T; M], &mut [T; N - M]);
}

However, const generics is not powerful enough for this today. See #83233 (comment) and #83233 (comment).

[jdahlstrom]

Hmm. Panicking if M > slice.len(), rather than returning a Result/Option, seems a bit surprising to me. I guess it's consistent with split_at, but on the other hand inconsistent with eg. split_first.

[scottmcm]

For the slice versions of these, I think it's important that they not only offer -> (&[T; N], &[T]), but also -> (&[T], &[T; N]). (This is basically the same as how there's both as_chunks and as_rchunks, see #78818.)

That might open up new naming possibilities too. To spitball:

• split_prefix: &[T] -> (&[T; N], &[T]) and
• split_suffix: &[T] -> (&[T], &[T; N])

[jplatte]

I agree that should exist, but I think it should be named rsplit_array since there's already a bunch of split functions whose "from the end" variations are all called rsplit*.

[yaahc]

I'd argue for local consistency over global consistency. In the case of slice we already have methods following both conventions, but the methods following the _prefix _suffix convention are related to stripping, where as the split methods all currently follow the split rsplit convention, so I lean towards keeping the current names.

[jethrogb]

Should there also be a shorthand API for slice[a..].split_array_ref::<B>() (the array version of &slice[a..(a+B)])?

[pmnoxx]

I think that the result should be an Option. This would allow us to properly handle splitting in case, the number of elements is lesser than the given contant.

impl<T, const N: usize> [T; N] {
    pub fn split_array_ref<const M: usize>(&self) -> Option<(&[T; M], &[T])>;
    pub fn split_array_mut<const M: usize>(&mut self) -> Option<(&mut [T; M], &mut [T])>;

    pub fn rsplit_array_ref<const M: usize>(&self) -> Option<(&[T], &[T; M])>;
    pub fn rsplit_array_mut<const M: usize>(&mut self) -> Option<(&mut [T], &mut [T; M])>;
}

I've been looking an api like that. However, it would be great to add a proper handling of cases, where split can't happen.

Consider

[1,2,3].split_array_ref<4>().is_none(); /// Would make sense if the split fails

/// It's useful for network code, to check if prefix has length at least 4 to decode the message.
/// This code can avoid any unwraps, because `u32::from_le_bytes` need array of 4 elements as input. 
if let Some((left, _) = [1,2,3,4,5].split_array_ref<4>() {
   println!("{}", u32::from_le_bytes(left));
}

[jethrogb]

split_at doesn't return an Option.

[pmnoxx]

split_at doesn't return an Option.

Yes, that's unfortunate. I think it would be great to add try_split_at api. This would simplify at lot of code.

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

    pub fn try_split_array_ref<const M: usize>(&self) -> Option<(&[T; M], &[T])>;
    pub fn try_split_array_mut<const M: usize>(&mut self) -> Option<(&mut [T; M], &mut [T])>;

    pub fn try_rsplit_array_ref<const M: usize>(&self) -> Option<(&[T], &[T; M])>;
    pub fn try_rsplit_array_mut<const M: usize>(&mut self) -> Option<(&mut [T], &mut [T; M])>;
}

For example:
Currently, I have to write code like this to use the api:

let ary = [127,0,0,1,55,66];

if ary.len() >= 4 {
   let (ip,_) = ary.split_at(4);
   ///. ...
}

I think it would be much cleaner to write it in a declarative way, which avoid hidden unwraps of getting a slice.

let ary = [127,0,0,1,55,66];

if let Some((ip,_)) = ary.try_split_at(4) {
  /// ...
}

Or even better

let ary = [127,0,0,1,55,66];

if let Some((ip,_)) = ary.try_split_array_ref<4>() {
  /// This makes ip a reference to 4 bytes array.
  /// ...
}

[scottmcm]

cc #95198, which proposes doing this more like the split_first family of things.

Those naturally would return Option, the same way that first & split_first return Option today.

[faern]

I definitely want infallible (fail at compile time) split methods on arrays. I want to be able to cut arrays up into smaller array chunks without any bounds checks at runtime. I know there are issues currently that won't allow this API today. But I think we should aim for a future where we can do that.

Being able to parse the content of arrays without paying more bounds checks or code bloat than needed is definitely desired both for readability and performance. ([0u8; 100]).split_array_ref::<10>().expect("out of bounds, will never happen) does not look nice and has a lot of code paths that we already know won't happen. If it was a compile time error we would not accidentally create bugs where the 10 was made into a too large number.

[faern]

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

This makes no sense IMO 🤔 Because the only time it would ever be None should be found at compile time. I know that's not possible now. But why introduce a large API surface and use up a bunch of good method names for something that's (hopefully)? a temporary limitation.

[Xiretza]

I agree with the comments above that the methods on &[T] should return Options, but as @faern said this makes no sense on arrays, where all size checks are known at compile time. In my opinion the API would ideally look like this (note also the rsplit_ methods on arrays, for completeness):

impl<T, const N: usize> [T; N] {
    pub fn split_array<const M: usize>(self) -> ([T; M], [T; N - M]);

    pub fn split_array_ref<const M: usize>(&self) -> (&[T; M], &[T; N - M]);
    pub fn split_array_mut<const M: usize>(&mut self) -> (&mut [T; M], &mut [T; N - M]);

    pub fn rsplit_array_ref<const M: usize>(&self) -> (&[T; N - M], &[T; M]);
    pub fn rsplit_array_mut<const M: usize>(&mut self) -> (&mut [T; N - M], &mut [T; M]);
}

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

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

But as noted in the OP, this requires more advanced const generics features. The alternative array API (returning slices for the "rest") would be possible today, but I think it'd be better to wait until the "proper" solution is possible rather than stabilizing something suboptimal.