diff options
| author | bors <bors@rust-lang.org> | 2021-01-13 07:38:58 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2021-01-13 07:38:58 +0000 |
| commit | 9f3998b4aa9d0eea3249fdd48b8b719185673d16 (patch) | |
| tree | 7fdf7bbe364fcb1e4d4be807401cf7365f1b28aa /compiler/rustc_codegen_llvm/src | |
| parent | fc93e4719c2ced744d75f0c281bb7ba29844bedd (diff) | |
| parent | 5584224fdacc0af6d72e023e247b1e3076fa44d8 (diff) | |
| download | rust-9f3998b4aa9d0eea3249fdd48b8b719185673d16.tar.gz rust-9f3998b4aa9d0eea3249fdd48b8b719185673d16.zip | |
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.
Diffstat (limited to 'compiler/rustc_codegen_llvm/src')
0 files changed, 0 insertions, 0 deletions
