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.

[krh]

Should we include split_once_mut and rsplit_once_mut?

I was just reaching for split_once_mut and didn't find it, so I'd vote yes...

[olivia-fl]

Should we include split_once_mut and rsplit_once_mut?

I was just reaching for split_once_mut and didn't find it, so I'd vote yes...

I think adding this is probably a good idea, but if we're going to add slice::split_once_mut we should also add str::split_once_mut. If we do that, I'm assuming str::split_once_mut should be a separate feature from this one?

Either way, I'm gonna wait until we have a decision on whether return types should include the delimiter (#119799) before submitting a PR for the _mut variants.

[cls]

I'm a newbie, but I thought I'd still stick my oar in. The change in #119799 seems fine, but I wondered if an alternative might be to leave returning the separator to a separate method.

In a vacuum that might seem clumsy, but my thinking is that, as @huonw said, returning the separator would be required for slice::split_once_mut, and I'm wondering whether that wouldn't also be true of str. If it would be then, if we left it to a separate method split_once_sep (or whatever), we could add the same method to str — at the same time as str::split_once_mut — which would then be more consistent between str::split_once and slice::split_once, but also internally within str, because then it wouldn't leave the question "why can I get a reference to the separator only for &mut str?".

However, this won't be an issue if the thinking is that str::split_once_mut would not return the separator either.

I don't know — food for thought.

[olivia-fl]

I like the split_once_sep proposal, for uniformity with the str API. Gonna mark #119799 as a draft and wait to see if anybody else has thoughts about this before trying to make any changes.

Another option might be to have something like str::split_inclusive, where the split element is included in the first return value. I think one of the arguments against that would be that the current api of slice::split_once ensures that the delimiter will always be a single element, which is not the case with str::pattern::Pattern. slice::split_once_inclusive would also be annoying to work with if you want a mutable reference to both the prefix and the delimiter.