Tracking Issue for slice_range

[dylni]

The feature gate for the issue is #![feature(slice_range)].

This issue currently tracks the following API:

pub mod slice {
    pub fn range<R>(range: R, bounds: RangeTo<usize>) -> Range<usize>
    where
        R: RangeBounds<usize>;
}

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Implement the feature (Add slice::check_range #75207)
• Adjust documentation (Adjust documentation for slice_check_range #76395)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

• Should this method be defined on RangeBounds or Range instead? (Move slice::check_range to RangeBounds #76885)
• Should a non-panicking version be added?
• Should this wait for #[final] methods in traits?
  • The main reason this isn't on RangeBounds is that today unsafe code can't trust any method on a not-unsafe trait to validate anything. But if this was a final method, and thus not overridable, then unsafe code could trust it.
• Switch to the new std::range return type

Implementation history

• Implemented in Add slice::check_range #75207
• Adjust documentation for slice_check_range #76395
• Changed type (taking only the length) in Fix liballoc test suite for Miri #76662
• Move slice::check_range to RangeBounds #76885
• Renamed to slice::range in Improve design of assert_len #81154
• add #[must_use] to functions of slice and its iterators. #95274
• Add slice::try_range #121148

[RalfJung]

With #75207 the type of this function changed, so the issue description should likely be adjusted -- unless you want to provide the old one as a convenience wrapper? I think that would be a bad idea though. The function's docs clearly position it as something used in unsafe code, and in unsafe code I'd rather not make people create slices when all they need is to compute their length. As #76662 showed, often creating those slices is not correct.

[RalfJung]

Alternatively, maybe it would make more sense to make this a method on RangeBounds?

[dylni]

Well, the reason I chose to define it on a slice is that (I think) it's not possible to create a slice of length usize::MAX without a custom allocator. Thus, panicking for an inclusive usize::MAX index is reasonable. I didn't want this method to cause developers to always ignore ..=usize::MAX, even though I don't know why you'd need a range that large.

Outside the standard library, wouldn't &[MaybeUninit] be necessary to create an uninitialized slice anyway?

[RalfJung]

Well, the reason I chose to define it on a slice is that (I think) it's not possible to create a slice of length usize::MAX without a custom allocator.

It is possible though: &[(); usize::MAX].

Outside the standard library, wouldn't &[MaybeUninit] be necessary to create an uninitialized slice anyway?

This applies inside and outside the standard library. The alternative is a raw slice, *const [T].

[dylni]

It is possible though: &[(); usize::MAX].

Right, that's what I was missing.

This applies inside and outside the standard library. The alternative is a raw slice, *const [T].

I agree the API change makes sense now. Thanks for the explanations!

I also fixed the code sample in this issue.

[dylni]

Alternatively, maybe it would make more sense to make this a method on RangeBounds?

Now that it doesn't need a slice, I think this might be better. I'll think about it and likely create a PR to move it.

[dylni]

@RalfJung

Alternatively, maybe it would make more sense to make this a method on RangeBounds?

Is this possible? I don't think provided methods can restrict the trait's type parameter at all, but Add and PartialOrd would be required at least. It could be defined for (Bound<usize>, Bound<usize>), but that seems worse.

[RalfJung]

Is this possible? I don't think provided methods can restrict the trait's type parameter at all, but Add and PartialOrd would be required at least. It could be defined for (Bound, Bound), but that seems worse.

Hm, you could play with something like fn provided(self) where Self: Bound.

[dylni]

Hm, you could play with something like fn provided(self) where Self: Bound.

Thanks. I'm not sure how I missed bounds on the method itself.