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

zachs18 · 2025-07-19T06:55:41Z

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

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:

Type inference regressions: See @SimonSapin's explanation from a previous PR: Add ?Sized bounds to all the RangeBounds impls #61584 (comment)
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

"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 · 2025-07-19T06:55:45Z

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

tgross35 · 2025-07-23T09:47:00Z

library/core/src/ops/range.rs

+/// This impl intentionally does not have `T: ?Sized` due to type inference issues.
+// see https://github.com/rust-lang/rust/pull/61584 for discussion of those issues
+///
+/// If you need to use this impl where `T` is unsized,
+/// consider using the `RangeBounds` impl for a 2-tuple of [`Bound<&T>`][Bound],
+/// e.g. replace `start..` with `(Bound::Included(start), Bound::Unbounded)`.


Few small nits/thoughts:

I don't think the "due to type inference issues" part needs to be in public docs. That reasoning is a bit of an internal detail, I think it's fine to just make the whole first sentence a non-doc comment.

Maybe "impl" -> "implementation" for prose

e.g. -> i.e. probably works because it's showing a pattern rather than a specific example

Looks like the paragraph needs a rewrap (100 chars)

Okay, I've made that part a non-doc comment, and made it not mention the reasoning, just link to it.

👍

👍

The longest of the added lines in the source is ~86 characters; do you mean the length in the rendered docs?

Ah sorry, yeah the length is fine but it just looks like it got some random/copy+paste wrapping (e.g. there's plenty of room for "consider using the RangeBounds" the next line up). Not going to block on that though, the rest lgtm.

Thanks for the updates!

…ntentionally not `T: ?Sized`, and document (publically) an alternative.

tgross35 · 2025-07-29T03:28:25Z

@bors r+ rollup

bors · 2025-07-29T03:28:28Z

📌 Commit 477814a has been approved by tgross35

It is now in the queue for this repository.

…ason, 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: * rust-lang#61584 * rust-lang#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: rust-lang#61584 (comment) 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 rust-lang#107196 (as wontfix) CC rust-lang#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"?

Rollup of 14 pull requests Successful merges: - #144022 (Implementation: `#[feature(sync_nonpoison)]`, `#[feature(nonpoison_mutex)]`) - #144167 (Document why `Range*<&T> as RangeBounds<T>` impls are not `T: ?Sized`, and give an alternative.) - #144407 (fix(debuginfo): disable overflow check for recursive non-enum types) - #144451 (fix: Reject upvar scrutinees for `loop_match`) - #144482 (Add explicit download methods to download module in bootstrap) - #144500 (thread name in stack overflow message) - #144511 (tidy: increase performance of auto extra checks feature) - #144586 (Update wasi-sdk to 27.0 in CI) - #144599 (bootstrap: enable tidy auto extra checks on tools profile) - #144600 (Ensure external paths passed via flags end up in rustdoc depinfo) - #144609 (feat: Right align line numbers) - #144623 (miri subtree update) - #144626 (cc dependencies: clarify comment) - #144627 (Add a test case for the issue #129882) r? `@ghost` `@rustbot` modify labels: rollup

Rollup of 13 pull requests Successful merges: - #144022 (Implementation: `#[feature(sync_nonpoison)]`, `#[feature(nonpoison_mutex)]`) - #144167 (Document why `Range*<&T> as RangeBounds<T>` impls are not `T: ?Sized`, and give an alternative.) - #144407 (fix(debuginfo): disable overflow check for recursive non-enum types) - #144451 (fix: Reject upvar scrutinees for `loop_match`) - #144482 (Add explicit download methods to download module in bootstrap) - #144500 (thread name in stack overflow message) - #144511 (tidy: increase performance of auto extra checks feature) - #144599 (bootstrap: enable tidy auto extra checks on tools profile) - #144600 (Ensure external paths passed via flags end up in rustdoc depinfo) - #144609 (feat: Right align line numbers) - #144623 (miri subtree update) - #144626 (cc dependencies: clarify comment) - #144627 (Add a test case for the issue #129882) r? `@ghost` `@rustbot` modify labels: rollup

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: * #61584 * #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: #61584 (comment) 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 #107196 (as wontfix) CC #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"?

…ason, 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: * rust-lang#61584 * rust-lang#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: rust-lang#61584 (comment) 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 rust-lang#107196 (as wontfix) CC rust-lang#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"?

Rollup of 13 pull requests Successful merges: - rust-lang/rust#144022 (Implementation: `#[feature(sync_nonpoison)]`, `#[feature(nonpoison_mutex)]`) - rust-lang/rust#144167 (Document why `Range*<&T> as RangeBounds<T>` impls are not `T: ?Sized`, and give an alternative.) - rust-lang/rust#144407 (fix(debuginfo): disable overflow check for recursive non-enum types) - rust-lang/rust#144451 (fix: Reject upvar scrutinees for `loop_match`) - rust-lang/rust#144482 (Add explicit download methods to download module in bootstrap) - rust-lang/rust#144500 (thread name in stack overflow message) - rust-lang/rust#144511 (tidy: increase performance of auto extra checks feature) - rust-lang/rust#144599 (bootstrap: enable tidy auto extra checks on tools profile) - rust-lang/rust#144600 (Ensure external paths passed via flags end up in rustdoc depinfo) - rust-lang/rust#144609 (feat: Right align line numbers) - rust-lang/rust#144623 (miri subtree update) - rust-lang/rust#144626 (cc dependencies: clarify comment) - rust-lang/rust#144627 (Add a test case for the issue rust-lang/rust#129882) r? `@ghost` `@rustbot` modify labels: rollup

rustbot assigned tgross35 Jul 19, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jul 19, 2025

tgross35 reviewed Jul 23, 2025

View reviewed changes

Document (internally) that Range*<&T> as RangeBounds<T> impls are i…

477814a

…ntentionally not `T: ?Sized`, and document (publically) an alternative.

zachs18 force-pushed the rangebounds-not-unsized-reason branch from 972b7e9 to 477814a Compare July 23, 2025 20:39

tgross35 approved these changes Jul 29, 2025

View reviewed changes

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 29, 2025

Zalathar mentioned this pull request Jul 29, 2025

Rollup of 14 pull requests #144628

Closed

Zalathar mentioned this pull request Jul 29, 2025

Rollup of 13 pull requests #144633

Merged

bors merged commit 9cba498 into rust-lang:master Jul 29, 2025
11 checks passed

rustbot added this to the 1.90.0 milestone Jul 29, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

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

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

Uh oh!

zachs18 commented Jul 19, 2025

Uh oh!

rustbot commented Jul 19, 2025

Uh oh!

tgross35 Jul 23, 2025

Uh oh!

zachs18 Jul 23, 2025

Uh oh!

tgross35 Jul 29, 2025

Uh oh!

tgross35 commented Jul 29, 2025

Uh oh!

bors commented Jul 29, 2025

Uh oh!

Uh oh!

Uh oh!

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

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

Uh oh!

Conversation

zachs18 commented Jul 19, 2025

Footnotes

Uh oh!

rustbot commented Jul 19, 2025

Uh oh!

tgross35 Jul 23, 2025

Choose a reason for hiding this comment

Uh oh!

zachs18 Jul 23, 2025

Choose a reason for hiding this comment

Uh oh!

tgross35 Jul 29, 2025

Choose a reason for hiding this comment

Uh oh!

tgross35 commented Jul 29, 2025

Uh oh!

bors commented Jul 29, 2025

Uh oh!

Uh oh!

Uh oh!

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

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