slice[slice.len()..] doesn't result in an index out of bounds error

[petrochenkov]

.. ranges are [inclusive, exclusive) and index access is normally bounds checked, e.g. slice[slice.len()+100..] or slice[slice.len()] panics, however slice[slice.len()..]/slice[slice.len()..slice.len()] is an exception, it just returns an empty slice despite the first inclusive index being out of bounds.

I agree this is convenient and I guess this was implemented intentionally, and we can't silently break this now, but it at least needs to be 1) documented as intentional behavior, 2) tested as intentional behavior.
So far I haven't found neither documentation, nor tests, nor design rationale in the range indexing RFCs and their implementations.

[bluss]

It's definitely intentional that len is a valid slicing index. Our problem is that we use no documentation at all (in rustdoc) for trait implementations. Index for slice and str should have this information.

[petrochenkov]

Our problem is that we use no documentation at all (in rustdoc) for trait implementations.

Doc-comments in the source code would be enough for a start, even if they are not displayed by rustdoc.

[bluss]

start <= end && end <= .len() is pretty ingrained, is drain really the only place that spells it out completely? http://doc.rust-lang.org/nightly/collections/vec/struct.Vec.html#method.drain

We need more people to tell about doc blind spots like this!

[steveklabnik]

Fixed by #32099

[bluss]

I need to follow it up with an improvement for slice slicing as well. (Pr was for strings).