Tracking issue for `[T]::rsplit` and `[T]::rsplit_mut`

[jorendorff]

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.

[bluss]

I don't think this improvement needs an RFC. It seems like Rsplit needs to use a distinct iterator type for encapsulation so that it can be distinct when subslice splitting finally comes around?

[jorendorff]

OK, no RFC. Working on a patch. @bluss Is a feature flag needed for this?

[bluss]

Yes, the usual way is that you invent a new feature name for it and introduce as unstable.

[jorendorff]

OK, thanks. I don't need to add it to libsyntax/feature_gate.rs though, right?

[bluss]

Correct, that's for language (this is library) feature gates.

[jorendorff]

PR #41065.

[SimonSapin]

This should not have been closed since it is the tracking issue for unstable APIs.