Document why Range*<&T> as RangeBounds<T> impls are not T: ?Sized, and give an alternative.

[zachs18]

Range*<&T> as RangeBounds<T> impls have been tried to be relaxed to T: ?Sized at least twice:

• Add ?Sized bounds to all the RangeBounds impls #61584
• Expand upper bounds on RangeBounds impls #64327

I also was just about to make another PR to do it again until I ./x.py test library/alloc and rediscovered the type inference regression, then searched around and found the previous PRs. Hence this PR instead so hopefully that doesn't keep happening 😛.

These impls cannot be relaxed for two reasons:

1. Type inference regressions: See @SimonSapin's explanation from a previous PR: Add ?Sized bounds to all the RangeBounds impls #61584 (comment)
2. It's a breaking change: impl RangeBounds<MyUnsizedType> for std::ops::Range<&MyUnsizedType> is allowed after the coherence rebalance (playground link), and relaxing these impls would conflict with that downstream impl.

This PR adds doc-comments explaining that not having T: ?Sized is intentional¹, and gives an explicit alternative: (Bound<&T>, Bound<&T>).

Technically, the impls for the unstable new std::range types could be relaxed, as they are still unstable so the change would not be breaking, but having them be different in this regard seems worse (and the non-iterable RangeTo/RangeToInclusive range types are shared between the "new" and "old" so cannot be changed anyway), and then the type inference regression would pop up in whatever edition the new range types stabilize in.

The "see <link> for discussion of those issues" is intentionally left as a non-doc comment just for whoever may try to relax these impls again in the future, but if it is preferred to have the link in the docs I can add that.

Closes #107196 (as wontfix)
CC #64027

Footnotes

1. "intentional" is maybe a bit of strong wording, should it instead say something like "was stabilized without it and it would be breaking to change it now"? ↩

[rustbot]

r? @tgross35

rustbot has assigned @tgross35.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer