Stabilize split_inclusive

[ijackson]

Contents of this MR

This stabilises:

• slice::split_inclusive
• slice::split_inclusive_mut
• str::split_inclusive

Closes #72360.

A possible concern

The proliferation of split_* methods is not particularly pretty. The existence of split_inclusive seems to invite the addition of rsplit_inclusive, splitn_inclusive, etc. We could instead have a more general API, along these kinds of lines maybe:

   pub fn split_generic('a,P,H>(&'a self, pat: P, how: H) -> ...
       where P: Pattern
       where H: SplitHow;

   pub fn split_generic_mut('a,P,H>(&'a mut self, pat: P, how: H) -> ...
       where P: Pattern
       where H: SplitHow;

   trait SplitHow {
       fn reverse(&self) -> bool;
       fn inclusive -> bool;
       fn limit(&self) -> Option<usize>;
   }

   pub struct SplitFwd;
   ...
   pub struct SplitRevInclN(pub usize);

But maybe that is worse.

Let us defer that?

This seems like a can of worms. I think we can defer opening it now; if and when we have something more general, these two methods can become convenience aliases. But I thought I would mention it so the lang API team can consider it and have an opinion.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @withoutboats (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[KodrAus]

Thanks @ijackson! We do have quite a lot of split methods on str, but I don't think these methods make that situation any worse than it currently is, and I don't think solutions to that proliferation require any new tools.

I think an API that might untangle things in the future could be to introduce something like a Splitter type that pulled the various ways of surfacing substrings and patterns off the str type itself:

// do:
s.splitter(pat).inclusive()
s.rsplitter(pat).inclusive()

// instead of:
s.split_inclusive(pat)
s.rsplit_inclusive(pat)

If we did want to do something like that and deprecate methods on str I don't think that would introduce any new problems of dealing with discoverability amongst a growing number of deprecated APIs than we already have.

[KodrAus]

These seem like reasonable additions to our split API to me that solve another set of use-cases where you want to keep the split pattern on the end of each substring.

@rfcbot fcp merge

[rfcbot]

Team member @KodrAus has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @KodrAus
• @dtolnay
• @sfackler
• @withoutboats

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[bors]

☔ The latest upstream changes (presumably #79895) made this pull request unmergeable. Please resolve the merge conflicts.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rust-log-analyzer]

The job mingw-check failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

    Checking rustc-rayon v0.3.0
    Checking tempfile v3.1.0
    Checking regex v1.3.9
    Checking rustdoc v0.0.0 (/checkout/src/librustdoc)
error: the feature `split_inclusive` has been stable since 1.49.0 and no longer requires an attribute to enable
   |
18 | #![feature(split_inclusive)]
   |            ^^^^^^^^^^^^^^^
   |
   |
   = note: `-D stable-features` implied by `-D warnings`
error: aborting due to previous error

error: could not compile `rustdoc`

[ijackson]

@rustbot modify labels -S-waiting-on-author

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

[KodrAus]

@bors r+

[bors]

📌 Commit 5584224 has been approved by KodrAus

[bors]

⌛ Testing commit 5584224 with merge 9f3998b...

[bors]

☀️ Test successful - checks-actions
Approved by: KodrAus
Pushing 9f3998b to master...

[jyn514]

Shouldn't since version be 1.51?

This was fixed before merging: 5584224