Tracking Issue for str_split_once

[matklad]

Feature gate: #![feature(str_split_once)]

Public API

impl str {
    pub fn split_once<'a, P: Pattern<'a>>(&'a self, delimiter: P) -> Option<(&'a str, &'a str)>;
    pub fn rsplit_once<'a, P: Pattern<'a>>(&'a self, delimiter: P) -> Option<(&'a str, &'a str)>;
}

Steps / History

• Implementation: Add str::[r]split_once #74707
• Final commenting period (FCP): Tracking Issue for str_split_once #74773 (comment)
• Stabilization PR: Stabilize str_split_once #81940

Unresolved Questions

• Should the method return the separator as well ((&str, &str, &str))? (str::split_once is underpowered #76512)
  • Tracking Issue for str_split_once #74773 (comment)

[LunaBorowska]

I wonder if it shouldn't return (&str, Option<&str>), I don't think the first element when using split method could ever be None.

[jsdw]

The way I am interpreting the current signature of Option<(&str,&str)> is that either the separator is matched, and so you get a pair of &strs (they might both be empty, but that's ok), or alternately the separator is not matched, in which case the splitting failed and so you get None. This seems consistent with other functions.

Returning (&str, Option<&str>) IMO leaves the meaning of the Option more open to interpretation (do you get None back if we failed to split, or if the second string is zero length?). Having the Option at the top level feels clearer to me (you get your two strings back if it worked, and nothing back if it didnt; I have difficulty working out how else I'd interpret it (which is good; don't want ambiguity)).

[Niedzwiedzw]

I've just used it in one of my projects and it felt very natural, I agree with your reasoning James

[yoshuawuyts]

Tried it today for a quick string matching script, and it felt really good to use. Not returning the separator felt consistent with str::split, which I've used a lot in the past. I think the API as-is is probably what it should be.

edit: probably two things to consider: vec::split_first also exists, and feels similar. Should this use the same name?

[clemenswasser]

I have used it here.

[CryZe]

I seems like the current implementation compiles in a bunch of panic checks, which shouldn't be necessary: https://rust.godbolt.org/z/WTTn6K

[matklad]

Yeah, the impl should be changed to use unchecked indexing (I believe there's no safe API we can use here), but it probably makes sense to do this after stabilization.

[matklad]

I think we should stabilize the API as is:

• many folks find this API useful
• it have been backing in the nightly for some (not too long) time
• the API surface is small enough that it feels unlikely we can improve this further

I think we should not complicate the API to return the ranged matched by the delimiter pattern: this makes the common case more difficult to use, and it goes inline with other pattern-using APIs. We can always add split_once_with_delim later, if we deem it necessary.

I don't think we should change the split_once name -- it feels like it fits the purpose well. split_first for &str would return a (char, &str) I think.

Is anyone willing to submit a stabilization PR? Or are there some concerns I am missing here.