bors 9f3998b4aa Auto merge of #77858 - ijackson:split-inclusive, r=KodrAus ... Stabilize split_inclusive ### 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.		2021-01-13 07:38:58 +00:00
..
benches	Reorder benches const variable	2020-09-29 21:39:24 +08:00
src	Add another test case for #79808	2021-01-11 12:10:16 +09:00
tests	Stabilize split_inclusive	2021-01-04 16:20:08 +00:00
Cargo.toml	Update compiler_builtins to 0.1.39	2021-01-07 16:16:36 +09:00