Tracking issue for `slice_take`

[cramertj]

Feature gate: #![feature(slice_take)]

Public API

impl<T> [T] {
    fn split_off<'a, R: OneSidedRange<usize>>(self: &mut &'a Self, range: R) -> Option<&'a Self>;
    fn split_off_mut<'a, R: OneSidedRange<usize>>(self: &mut &'a mut Self, range: R) -> Option<&'a mut Self>;
    fn split_off_first<'a>(self: &mut &'a Self) -> Option<&'a T>;
    fn split_off_first_mut<'a>(self: &mut &'a mut Self) -> Option<&'a mut T>;
    fn split_off_last<'a>(self: &mut &'a Self) -> Option<&'a T>;
    fn split_off_last_mut<'a>(self: &mut &'a mut Self) -> Option<&'a mut T>;
}


// core::ops

trait OneSidedRange<T: ?Sized>: RangeBounds<T> {}
impl<T> OneSidedRange<T> for RangeTo<T> where Self: RangeBounds<T>;
impl<T> OneSidedRange<T> for RangeFrom<T> where Self: RangeBounds<T>;
impl<T> OneSidedRange<T> for RangeToInclusive<T> where Self: RangeBounds<T>;

Steps / History

• Introduce <&[_]>::split_off and <&str>::split_off #49173
• Add take_... functions to slices #62282
• Take 2: Add take_... functions to slices #77065
• Add slice take methods #88502
• Rename slice::take... methods to split_off... #136555
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

[KodrAus]

Since the linked implementation PR is closed (just due to inactivity) we don't really have an issue to track yet. I'll go ahead and close this one, but if #62282 resurfaces in the future we can re-open!

[m-ou-se]

Re-opening because of #77065

[SimonSapin]

https://doc.rust-lang.org/nightly/std/ops/trait.OneSidedRange.html links to #69780 which is closed. Either it should be reopened (and some details filled in) or #[unstable] attributes should be changed to point here instead, depending on whether it’s useful to track OneSidedRange separately.

[lilyball]

Can we implement OneSidedRange for RangeFull as well? I'd like to be able to say self.slice.take(..) as a shorthand for std::mem::swap(&mut self.slice, &[]) (or I suppose for self.slice.take(0..)). This doesn't fit the naming OneSidedRange or the description that says the range is unbounded on one side¹, but I don't see any reason why RangeFull should not be usable here.

Footnotes

1. Technically it doesn't say it has to be bounded on the other side, but it does list .. as a non-compliant type. ↩

[andersk]

Can we implement OneSidedRange for RangeFull as well?

Perhaps also rename OneSidedRange to UnboundedRange, in that case?

[safinaskar]

Please, rename. Method take is unusable with its current name, because it conflicts with std::io::Read::take.

Let me describe my actual production use case.

First I read some data from file using std::io::Read::read_to_end. To be able to read data I have to write use std::io::Read. Then I started to parse that data using various functions, including <[T]>::take. But I was unable to do this because of use std::io::Read, see playground: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=e467873898a5f160420a5d6f13274ffa

[clarfonthey]

FYI: #69780 is still being linked for OneSideRange in the docs when that issue is closed; should the tracking issue be moved to here?

[jongiddy]

I agree with @safinaskar that a different name for take (and take_mut) should be considered. I like take_slice and take_slice_mut for the current API.

But changing the API to replace take(range) with take_before(usize) and take_after(usize) (and possibly take_all()) would be clearer and removes the need to resolve issues with OneSidedRange.

[jongiddy]

I'd love to see taking from a slice stabilized. But the introduction of OneSidedRange seems to be the wrong path to take. I looked at the previous discussion for the benefits of adding OneSidedRange. They are:

• "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"

OneSidedRange did not solve the method naming problem, the original design without OneSidedRange can also use regular indices rather than length from the end, and I don't see any other code that uses OneSidedRange. The only objective benefit realized from the above is that the number of methods reduced from 8 to 6.

Meanwhile the OneSidedRange code requires two match statements to turn the range parameter back into a single index and then call separate paths for the two possible directions. It also adds panic code for the unreachable variants when changing the range to an index and a direction.

The benefits of OneSidedRange just do not justify the additional complexity, especially as part of the standard library.

I propose the creation of a new implementation PR to remove OneSidedRange and replace take with take_before and take_after methods + _mut variants. I'm happy to make the PR (but also happy for someone else to do it). But I'd like to check if anyone is strongly opposed first.

cc @nox @cramertj @timvermeulen @ibraheemdev who worked on the previous implementation PR's.

[WaffleLapkin]

@safinaskar this conflict is indeed very unfortunate, however do note that there are workarounds. Notably you can:

• Import the Read trait in a different module or function (you can write use inside a function) than the usage of the take method
• Explicitly take mutable reference ((&mut s).take(..1))
• Explicitly write the function (<[_]>::take(&mut s, ..1))
• Use the method on a mut ref (s.take(..1) where s has type &mut &[_])

See playground.