Tracking issue for the SliceIndex trait

[alexcrichton]

Tracking issue for rust-lang/rfcs#1679

The implementations are stable, but the SliceIndex trait is not.

[sfackler]

This is now implemented and will land in the 1.15 release!

[sfackler]

Oh right, this should be the tracking issue for the unstable helper traits...

[briansmith]

Could we please stabilize this for the next release (or the next next release)? It seems like it is possible to use the new functionality, but it isn't possible to write (transparent) wrappers around it because any reference to the SliceIndex trait triggers "use of unstable library feature 'slice_get_slice' (see issue #35729)".

[alexcrichton]

@sfackler I forget, was this an intended "never to be stabilized" trait or did we want this on the track to stabilization?

@briansmith note that the trait can be vendored locally for now (if necessary) as it's not unstable to implement it, just to use the libstd version. Now that's a huge PITA (especially in multiple crates), but it at least gets the ergonomics immediately!

[sfackler]

I wouldn't call it a "never stabilize" kind of thing, but it's definitely a bit gross in its current form. One suggestion on the RFC was to split out a trait per method which could be a bit cleaner and more extensible in the future.

[briansmith]

@alexcrichton I don't know what you mean by "can be vendored." Here's what I'm trying to write:

#[derive(Clone, Copy, Debug, Eq, PartialEq)]
pub struct Slice<'a> {
    bytes: &'a [u8]
}

impl<'a> Slice<'a> {
    #[inline]
    pub fn new(bytes: &'a [u8]) -> Slice<'a> {
        Slice { bytes: bytes }
    }

    #[inline]
    pub fn get<I>(&self, i: I) -> Option<&I::Output>
                  where I: std::slice::SliceIndex<u8> {
        self.bytes.get(i)
    }
}

The result is "use of unstable library feature 'slice_get_slice' (see issue #35729))."

[alexcrichton]

@briansmith oh I just mean that you can add your own SliceIndex trait in your own local crate, add the various impls/methods you need, and then use it locally.

That'd work for one crate to get ergonomics, but it wouldn't work at large to continue abstracting over it.

[clarfonthey]

It'd be nice to see this trait combined with RangeArgument somehow.

[jonhoo]

@alexcrichton I'm not sure what you mean in your recommendation to @briansmith? I want to take a generic slice index argument (i.e., may be a range), and then use it to index into a slice. If I copy the trait into my own crate, I can't then take something implementing that trait and pass to slice::get?

[alexcrichton]

@jonhoo oh mean basically just copy/pasting the trait in libstd into your own crate. You wouldn't call <[T]>::get, you'd call the local trait's method. Again, good for library consumer ergonomics, bad for library developer ergonomics and generics

[SimonSapin]

#51147 implements #35729 (comment) except #[doc(hidden)], because of #13698.

[joshlf]

Would it be possible to add a blanket impl for RangeBounds? It's been discussed in this thread, but all that ended up going in was a series of impls for the particular Range types (RangeTo, RangeFull, etc).

[SimonSapin]

@joshlf Seems reasonable to me, wanna send a PR? With #51147 landed it would need to happen in this release cycle.

[SimonSapin]

Oh wait, I just remembered: that would replace specialized code with enum-based dispatch. I don’t know if that ends up being reliably optimized away.

[joshlf]

Couldn't we use impl specialization?

[SimonSapin]

If this doesn’t simplify the code, why is this blanker impl useful?

[joshlf]

It's useful because otherwise you can't write the following code (which I tried to do, which motivated my commenting here):

fn foo<R: RangeBounds<usize>>(buf: &mut [u8], range: R) {
    bar(&mut buf[range]);
}

[SimonSapin]

Can you have a bound on SliceIndex instead? That’s exactly why we stabilized the trait without stabilizing the methods.

[joshlf]

Unfortunately not - some of the code actually makes use of the methods on RangeBounds. E.g., this function, which needs the ability to query what the bounds are:

Click to expand

use zerocopy::ByteSlice;

/// Extract a range from a slice of bytes.
///
/// `extract_slice_range` extracts the given range from the given slice of
/// bytes. It also returns the byte slices before and after the range.
///
/// If the provided range is out of bounds of the slice, or if the range
/// itself is nonsensical (if the upper bound precedes the lower bound),
/// `extract_slice_range` returns `None`.
pub fn extract_slice_range<B: ByteSlice, R: RangeBounds<usize>>(
    bytes: B, range: R,
) -> Option<(B, B, B)> {
    let lower = resolve_lower_bound(range.start_bound());
    let upper = resolve_upper_bound(bytes.len(), range.end_bound())?;
    if lower > upper {
        return None;
    }
    let (a, rest) = bytes.split_at(lower);
    let (b, c) = rest.split_at(upper - lower);
    Some((a, b, c))
}

// return the inclusive equivalent of the bound
fn resolve_lower_bound(bound: Bound<&usize>) -> usize {
    match bound {
        Bound::Included(x) => *x,
        Bound::Excluded(x) => *x + 1,
        Bound::Unbounded => 0,
    }
}

// return the exclusive equivalent of the bound, verifying that it is in
// range of len
fn resolve_upper_bound(len: usize, bound: Bound<&usize>) -> Option<usize> {
    let bound = match bound {
        Bound::Included(x) => *x + 1,
        Bound::Excluded(x) => *x,
        Bound::Unbounded => len,
    };
    if bound > len {
        return None;
    }
    Some(bound)
}

[SimonSapin]

… then have two bounds?

[joshlf]

That doesn't work because generic code needs to call extract_slice_range. The only way to get it to work (which I do now) is to have a function which converts any pair of R: RangeBounds<usize> and a slice length into a Range. It works, but it's a real hack, and it requires code that looks like slice_mut(slice, range) rather than slice[range], where slice_mut is itself pretty annoying, and has to be used everywhere.

Click to expand

    pub fn slice_mut<'a, T, R: RangeBounds<usize>>(slc: &'a mut [T], range: &R) -> &'a mut [T] {
        let lower = resolve_lower_bound(range.start_bound());
        let upper = resolve_upper_bound(slc.len(), range.end_bound()).unwrap();
        &mut slc[lower..upper]
    }

    // return the inclusive equivalent of the bound
    fn resolve_lower_bound(bound: Bound<&usize>) -> usize {
        match bound {
            Bound::Included(x) => *x,
            Bound::Excluded(x) => *x + 1,
            Bound::Unbounded => 0,
        }
    }

    // return the exclusive equivalent of the bound, verifying that it is in
    // range of len
    fn resolve_upper_bound(len: usize, bound: Bound<&usize>) -> Option<usize> {
        let bound = match bound {
            Bound::Included(x) => *x + 1,
            Bound::Excluded(x) => *x,
            Bound::Unbounded => len,
        };
        if bound > len {
            return None;
        }
        Some(bound)
    }

[joshlf]

Oh, sorry, I guess you mean have the bound R: RangeBounds<usize> + SliceIndex? That works I suppose. It's just ugly, and I suspect other Rust programmers are going to run into this sharp corner a lot. It'd be better if it Just Worked. If we can't get the default impl working, then so be it, but so long as we can get it to work, I feel like it will round off an otherwise sharp corner.

[SimonSapin]

Yes, if you want to do with a generic type two things that each require a different trait, have your own code require both traits.

[joshlf]

Oh, and one other issue. Since SliceIndex takes a type parameter, and we don't support HKT, there's no way to just have R: RangeBounds<usize> + SliceIndex, so the caller would have to know the concrete type T in SliceIndex<T>.

[SimonSapin]

This higher-ranked trait bounds rather than types, but yeah, good point.

[CAD97]

Is there any chance of providing a way of implementing SliceIndex in the future (or telling the coherence checker that the impls won't be expanded)? Because as it stands, it's impossible to have a custom index type and support indexing str by ops::Range* of the custom index type.