nightly SliceIndex::get_unchecked, get_unchecked_mut docs

[ratmice]

Location

https://doc.rust-lang.org/std/slice/trait.SliceIndex.html#tymethod.get_unchecked
https://doc.rust-lang.org/std/slice/trait.SliceIndex.html#tymethod.get_unchecked_mut

Summary

The documentation for these methods state respectively:

Returns a shared reference to the output at this location

Returns a mutable reference to the output at this location

However these clearly return pointers rather than references.
Later on they state the following restrictions, which make sense for references but it isn't clear to me that this restriction is necessary for pointers.

Calling this method with an out-of-bounds index or a dangling slice pointer is undefined behavior even if the resulting reference is not used.

At the very least the s/reference/pointer/ change needs to be made there too.

[workingjubilee]

These are nightly-only traits that aren't particularly on-track for stabilization anytime soon, but yes, changing them to be correct on those counts would be fine.

[ratmice]

Indeed, while it's nightly only I wasn't actually going to call it from nightly, but was looking because of it's use in other stable functions, e.g. Slice::get_unchecked_mut.

Would make a patch, but I wasn't sure whether to leave the undefined behavior line in or whether it should be removed.

[workingjubilee]

@ratmice It's still UB, yeah! This is partly because it still has to fulfill the safety conditions of pointer::add. Obviously, that isn't a full justification: there is the question of adding until the pointer is offset to the "last element", which would not trigger "language UB" via that implementation detail...

But the library defines it as UB, which means the implementation may include code that would cause an optimizer to see that it is "impossible" for the defined-UB result to happen. And the question of whether the "surface functions" have this obligation was settled in #117039 so yes, the same conclusion applies.