https://github.com/rust-lang/rust/pull/49173 - nox PR for split_at, split_off - 1
https://github.com/rust-lang/rust/pull/62282#issuecomment-523460168 - comment that brings up range idea
https://github.com/rust-lang/rust/issues/62280 - Tracking issue that introduces OneSidedRange
https://github.com/rust-lang/rust/pull/62282 - Implementation issue that introduces OneSidedRange - 2 - many comments on API
https://github.com/rust-lang/rust/issues/69780 - Tracking issue for OneSidedRange
https://github.com/rust-lang/rust/pull/77065 - Implementation PR revival - 3
https://github.com/rust-lang/rust/pull/88502 - Implementation PR revival that actually got merged - 4

self: &mut &'a Self is unusual - https://github.com/rust-lang/rust/pull/49173#issuecomment-379672665, https://github.com/rust-lang/rust/pull/88502#pullrequestreview-819861991
split_off shadows Vec::split_off - https://github.com/rust-lang/rust/pull/49173#issuecomment-379758751
take() has an internal panic for incorrect ranges
OneSidedRange only works for usize - https://github.com/rust-lang/rust/pull/77065#discussion_r519045519
OSR reduces number of method names - https://github.com/rust-lang/rust/pull/62282#issuecomment-575404362
OSR reduces bike-shedding - https://github.com/rust-lang/rust/pull/62282#issuecomment-575404362 - does it though?
OSR

PR 4: The OneSidedRange is introduced solely to allow the use of range notation to provide a single index and a direction.
Rather than OneSidedRange range helping in any particular way, the Implementation requires two match statements to undo the "rangification".
If anything, take_before/take_after should be std library and anyone who wants OSR can create a crate.
I propose to return to two separate functions taking a single usize, one equivalent to start.. and one equivalent to ..end. (4 functions in total with mut variants).


take_before/take_after - obvious with the index as only argument. Clear that take_after returns the slice from the index (not that number of elements)
take_at/take_off - ambiguous but take_off does match Vec/String split_off, but that does not have split_at - split_at means return two entries without changing self
take_left/take_right - rotate_left/rotate_right left and right have different meaning
take_prefix/take_suffix = matches strip_prefix/strip_suffix, but suffix is a pattern, not a length
take with a direction - doesn't match other uses of take which replace the entire object
take_start/take_end - matches str::trim_start/trim_end. Not clear whether take_end returns from index or number of elements

Some thought as to whether there should be a take_all. I think take_after(0) is a reasonable alternative unless we find that take_all can be more efficient.

Implement take_first/last using split_first/last https://github.com/rust-lang/rust/pull/77065#issuecomment-705417944
All return Options to allow unwrap or expect to cause a panic.

Benefits of OSR:
- "pretty neat"
- "looks nice"
- "works with regular indices rather than distances from the end of the slice"
- "don't have the method naming problem and don't have to add so many methods"
- "might be useful in a couple of other scenarios"

Of these, the strongest is probably the reduction in the number of methods. But we are talking 4 down to 2.

Benefits of not OSR
- "more usable and understandable"
New types add complexity.

- use `take_slice` instead of `take`
- panic on out of bounds, to reduce use of unwrap
- remove `must_use`
- support .. to empty out slice, e.g. for while loop
