Tracking Issue for `slice_split_once`

[olivia-fl]

Feature gate: #![feature(slice_split_once)]

This is a tracking issue for the slice::split_once and slice::rsplit_once methods, which split a slice into two chunks on the first occurrence of a single-element delimiter. These mirror the existing stable str::split_once and str::rsplit_once. I expect these to be mostly used for ad-hoc parsing data that is not UTF-8.

Public API

// core::slice

impl [T] {
    pub fn split_once<F>(&self, pred: F) -> Option<(&[T], &[T])>
    where
        F: FnMut(&T) -> bool;
    pub fn rsplit_once<F>(&self, pred: F) -> Option<(&[T], &[T])>
    where
        F: FnMut(&T) -> bool;
}

Steps / History

• ACP: ACP: add slice::split_once libs-team#102
• Implementation: Implement slice::split_once and slice::rsplit_once #112818
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• Should we include split_once_mut and rsplit_once_mut?

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[matklad]

Hm, I would have expect the following signature here:

pub fn split_once<F>(&self, delim: &[T]) -> Option<(&[T], &[T])>

With the predicate, we allow only single-element delimiters, which I think lowers the added utility here. With slice-delimiter, this function also encapsulates index + delim.len() computation.

With str and Pattern API we of course get all three of T, Fn(&T) -> bool, &[T] delimiters, but my personal experience is that the third version is by far the most useful one (and the first version is a special-case of the third anyway).

[olivia-fl]

Yeah, I generally think &[T] is more useful too, however all of the existing split methods in slices use a single-element predicate. Since these new methods is supposed to be analogous with the existing slice::{split,rsplit} methods, I think using &[T] here would be particularly confusing.

It's probably too late to introduce a Pattern-like API for slices in a backwards-compatible way, or switch the existing methods to work with &[T]. Either way, that should probably be it's own change.

[huonw]

For slices with arbitrary T, the split element isn't necessarily obvious or simple. Is it worth returning Option<(&[T], &T, &[T])> to have easier direct access to that element? (If/when a &mut version is added, this will be required, because reindexing to get the split element won't work.)

[olivia-fl]

Hmm, yeah I like that in the abstract. I think the main argument against it is that it's inconsistent with the existing split_* methods on both str and slice. I've definitely wanted something similar in the past when using str::split_once with a function pattern, so I don't think that the reasons for wanting access to the split delimiter are specific to arbitrary T.

[cls]

The doc comments for these methods look to have a typo currently, which I just tripped over in the docs: "If any matching elements are resent in the slice [...]". After a moment of confusion ("resent? re-sent? recent?"), I realised that they were probably meant to read present. I'd happily patch it but I'm not familiar with the process, so I thought I'd just mention it here instead.

[jhpratt]

"present" is presumably correct. As for process, just open a PR. Someone will be assigned to review it — don't worry if it takes a while.