Tracking issue for [T]::rsplit and [T]::rsplit_mut · Issue #41020 · rust-lang/rust (original) (raw)
Update (@SimonSapin): this is now a tracking issue for methods implemented in #41065.
In @brson's tech review of Programming Rust, when he got to the bit where we list all the slice methods, he wrote: "What about 'rsplit' (no 'n')?"
I thought, oh no, I missed a method. But there really isn't a [T]::rsplit method!
| str | [T] |
|---|---|
| .split(p) | .split(p) |
| .rsplit(p) | nope |
| .splitn(p) | .splitn(p) |
| .rsplitn(p) | .rsplitn(p) |
Slices don't have .rsplit(p), I guess maybe because .split(p).rev() does exactly what .rsplit(p) would do. (The two are subtly different for strings, in cases where the pattern can have overlapping matches.)
But is that a good enough reason to "break symmetry"?
@brson either really expected rsplit to exist, or he was speaking up for a hypothetical reader, new to Rust, who might expect it. Either way, I think it should be added, just to reduce by 1 the number of curious wrinkles in libcore. I'll write an RFC if this seems reasonable.