about summary refs log tree commit diff
path: root/compiler/rustc_codegen_llvm/src
diff options
context:
space:
mode:
authorbors <bors@rust-lang.org>2021-01-13 07:38:58 +0000
committerbors <bors@rust-lang.org>2021-01-13 07:38:58 +0000
commit9f3998b4aa9d0eea3249fdd48b8b719185673d16 (patch)
tree7fdf7bbe364fcb1e4d4be807401cf7365f1b28aa /compiler/rustc_codegen_llvm/src
parentfc93e4719c2ced744d75f0c281bb7ba29844bedd (diff)
parent5584224fdacc0af6d72e023e247b1e3076fa44d8 (diff)
downloadrust-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