impl<T> SliceIndex<[T]> for (Bound<usize>, Bound<usize>)

[ExpHP]

These feel like an omission to me, given how RangeArgument is implemented for this type:

impl<T> SliceIndex<[T]> for (Bound<usize>, Bound<usize>) { ... }
impl SliceIndex<str> for (Bound<usize>, Bound<usize>) { ... }

And if we really want to go for feature parity, then RangeArgument also has impls for (Bound<&T>, Bound<&T>), but I think that's mostly for the sake of methods like BTreeSet::range, and it really doesn't make sense here.
Edit: Then again, considering that RangeArgument is going to have methods that return Bound<&T>, maybe (Bound<&usize>, Bound<&usize>) is worth it.

---

(secretly, I just want the standard library to implement my bounds-checking and length-computation for me in my n-dimensional array, so that I can just write vec![(); len][(start_bound, end_bound)].len() and trust that it's correct. But shhhhhh, don't tell anyone)

[ExpHP]

On second thought, after seeing how meager libcore's test suite is for the existing indexing operations, I have decided that I should stop trusting the standard library and start contributing to it myself.

Working on a PR.

---

Edit: awww, looks like there's actually a good reason why there's no tests with vec![(); usize::MAX] or &[(); usize::MAX]. (the first takes forever on debug, the second sets forth The End of All Times)

---

Edit 2: How on earth does ..= not appear a single time in the tests for slice or str!?!

[AnthonyMikh]

@ExpHP do you still have plans to make a PR for this feature?

[ExpHP]

Nope, totally forgot about this! Feel free to take the reins.

(looking back, it seems I went ahead with the test suite PR (#50010), but that took long enough to merge that by the time it was done I must have moved on to other things.)