rust/library/core/src/ops
Stuart Cook 9cba49896c
Rollup merge of #144167 - zachs18:rangebounds-not-unsized-reason, r=tgross35
Document why `Range*<&T> as RangeBounds<T>` impls are not `T: ?Sized`, and give an alternative.

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

* https://github.com/rust-lang/rust/pull/61584
* https://github.com/rust-lang/rust/pull/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: https://github.com/rust-lang/rust/pull/61584#issuecomment-499601046
2. It's a breaking change: `impl RangeBounds<MyUnsizedType> for std::ops::Range<&MyUnsizedType>` is allowed after the coherence rebalance ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=f704a6fe53bfc33e55b2fc246d895ec2)), and relaxing these impls would conflict with that downstream impl.

This PR adds doc-comments explaining that not having `T: ?Sized` is intentional[^1], 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 https://github.com/rust-lang/rust/issues/107196 (as wontfix)
CC https://github.com/rust-lang/rust/issues/64027

[^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"?
2025-07-29 20:19:48 +10:00
..
arith.rs fix const_ops tracking issue 2025-07-11 17:57:50 +02:00
async_function.rs Make AsyncFnOnce, AsyncFnMut, AsyncFn non-#[fundamental] 2025-02-08 02:45:29 +01:00
bit.rs fix order on shl impl 2025-03-03 09:51:51 +01:00
control_flow.rs Tracking the old name of renamed unstable library attribute 2025-06-12 19:24:11 +08:00
coroutine.rs Add must_use attribute to Coroutine trait 2024-08-12 19:27:57 -07:00
deref.rs clippy fix: rely on autoderef 2025-07-04 11:35:00 +00:00
drop.rs clippy fix: indentation 2025-07-04 11:52:17 +00:00
function.rs update issue number for const_trait_impl 2025-07-13 23:55:06 +08:00
index.rs constify Index trait and its slice impls 2025-07-15 08:27:15 +00:00
index_range.rs Add some track_caller info to precondition panics 2025-05-21 09:10:06 -04:00
mod.rs Tracking the old name of renamed unstable library attribute 2025-06-12 19:24:11 +08:00
range.rs Document (internally) that Range*<&T> as RangeBounds<T> impls are intentionally not T: ?Sized, and document (publically) an alternative. 2025-07-23 15:39:03 -05:00
try_trait.rs Constify Try, From, TryFrom 2025-07-21 12:49:45 +03:00
unsize.rs library/compiler: add PointeeSized bounds 2025-06-16 23:04:33 +00:00