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.

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.

[scottmcm]

I think having the #76885 version of this for precondition checking is great.

I'm dropping by from #77480 (comment) to ponder whether there's other, more user-focused versions of this that could make sense too. Spitballing: something on SliceIndex like .check_index(x) that could return Result<Range<usize>, _>, targeted more at users who want to check things before calling other methods than at people implementing APIs that take RangeBounds.

[dylni]

@scottmcm

Spitballing: something on SliceIndex like .check_index(x) that could return Result<Range<usize>, _>, targeted more at users who want to check things before calling other methods than at people implementing APIs that take RangeBounds.

The problem with adding it to SliceIndex is that there's no way to represent usize as Range<usize>, so users would end up going back to RangeBounds anyway. However, a non-panicking version of assert_len might be a good idea. I added it to the unresolved questions, but it can even be added after this method is stabilized.

[clarfonthey]

Note: I didn't even realise this method existed despite searching for it, and ended up adding an implementation of SliceIndex for (Bound<usize>, Bound<usize>), which could potentially be a better way of doing this? Both could coexist but I haven't thought enough about how that would happen.

[dylni]

I thought about that. Also, this is the PR for anyone reading this issue: #81108

I think it depends on how you expect your impl to be used. Would it be used in a way this method would already cover? The advantage of this method is that it can be used when you don't have a slice:

rust/library/alloc/src/collections/vec_deque/mod.rs

Line 1068 in 95cbcad

let Range { start, end } = range.assert_len(self.len());

However, the design has changed a few times, so it's worth discussing what would be best.

[RalfJung]

IMO assert_len is not a great name, since it sounds like this is asserting the length of the range. It is impossible to tell what this function does without reading the docs. In this regardg, IMO it is worse than the previous slice::check_bounds(len, range).

The assert in the name makes sense because it panics on OOB, but on the other hand usually assert functions don't return anything. This function does both an assert and actually converts the indices to Range, so that will be tricky to express.

[scottmcm]

Idea: it could take RangeTo<usize> to help clarify the meaning of the argument, without introducing overhead.

That would allow a call like range.assert_subset_of(..self.len()), pending bikeshedding.

[dylni]

IMO assert_len is not a great name, since it sounds like this is asserting the length of the range.

Naming this method has always been a problem. That was simply the best name I found at the time, and I'd be in favor of changing it.

That would allow a call like range.assert_subset_of(..self.len()), pending bikeshedding.

This is a great idea. To avoid confusion with other assert_* items, maybe ensure_subset_of would be better. I'll open a PR later with this new design to continue the discussion.

[dylni]

I created the PR: #81154

[bluss]

As @xfix detected in #81157, this method is mildly dangerous (NOTE: current iteration when this comment was posted). The method cannot be trusted for asserting safety-critical invariants, because the trait is neither sealed nor an unsafe trait.

[dylni]

Thanks @bluss.

[jendrikw]

Could slice::split_point_of benefit from this?

[dylni]

@jendrikw Unfortunately, I doubt it. This function is used primarily to apply a length to a range, but the length for split_point_ofis irrelevant. This function returns the same range for (Unbounded, Excluded(length)) and (Included(0), Unbounded), for example.

[reitermarkus]

@dylni, given the implementation of slice:range hasn't changed in almost 4 years, is this ready to be stabilised?

[dylni]

@reitermarkus Personally, I no longer have a use for this method, so I cannot comment on if the current implementation is useful and makes sense. Do you have examples of this method providing benefit outside of libstd?

[reitermarkus]

I used it in heapless to implement Vec::drain, which basically mirrors the std::Vec::drain implementation: rust-embedded/heapless#444

Stabilising would reduce the amount of code that needs to be duplicated, as is currently the case.

[jonhoo]

I've also had a use for it recently in an API that I would like to be able to take an argument of type impl RangeBounds<usize> (just like Vec::drain). Seems like this method is the (only?) way to turn impl RangeBounds<usize> into Range<usize> in std.

[clarfonthey]

Since so many people mentioned it, I opened #121148 to add try_range, which returns an Option instead of panicking. It just feels weird not having the pair together, and hopefully having both will make this more comfortable to stabilise.

[dylni]

@reitermarkus Would you be able to create the stabilization report? Unfortunately, as I no longer make use of the feature and am not familiar with the stabilization process, I may not have the time to devote for a while. If not, I will look to create one once as soon as I have the opportunity.

[Dylan-DPC]

@reitermarkus Would you be able to create the stabilization report? Unfortunately, as I no longer make use of the feature and am not familiar with the stabilization process, I may not have the time to devote for a while. If not, I will look to create one once as soon as I have the opportunity.

we just added a new function which isn't merged yet and is tied to the same tracking issue, so we need to spend some time for it to »bake« if we plan on stabilising this all together. We could move it to a different feature gate, but for a small feature like this, I'm not sure that's a good idea.

it's fine if you can't write the stabilisation report. The person who opens the tracking issue isn't obliged to write the stabilisation report, so once we give enough time for this, I will try and look towards writing the stabilisation report for it

[dtolnay]

#95274 added #[must_use] to this function, which seems potentially overbearing to me. Is #[must_use] a net benefit for slice::range? Or would it be common to call only for the bounds checking/panic side effect?

Of course for slice::try_range a #[must_use] is appropriate because that one has no side effect.

[scottmcm]

@dtolnay To me, the point of slice::range is that you can't trust an impl RangeBounds, so it's incorrect to use slice::range for its bounds checking side effect only -- the next time you call .end_bound() it might give something different. So you must use the returned Range rather than the input.

Though of course it would be nice if the must_use actually said something like that. (I'm still kinda sad we're adding empty must_uses that don't have anything custom to say, rather than just making a better lint that warns on more things.)

[dtolnay]

Good call. Now must_use makes sense to me. Thank you!

I searched GitHub for "start <= end &&" and there are a few hits that might be able to correctly use slice::range without using the return value, in code that does not involve impl RangeBounds:

• https://github.com/SpectralSequences/sseq/blob/946d52eda4cc8728da2173eceec74124a1398244/ext/crates/fp/src/vector/impl_slicep.rs#L72
• https://github.com/loro-dev/loro/blob/a47cf06712f6992f7f3de43be00c19fe522acd64/crates/loro-internal/src/container/richtext/tinyvec.rs#L155

but arguably those are APIs that would be better redesigned to use impl RangeBounds instead of start: usize, end: usize, and if not, writing slice::range(start..end, ..self.len); is not a definite improvement over the assert they currently have.

If someone wants to extend the documentation of slice::range to point out why the return value can be necessary for soundness in the situation of an untrusted RangeBounds impl, #81138 has an example of a real-world bug like that.