Github Stabilize split_inclusive by ijackson · Pull Request #77858 · rust-lang/r...

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.