Incoming breakage: Remove unnecessary ?Sized bounds#14
Open
fmease wants to merge 1 commit intoGui-Yom:masterfrom
Open
Incoming breakage: Remove unnecessary ?Sized bounds#14fmease wants to merge 1 commit intoGui-Yom:masterfrom
?Sized bounds#14fmease wants to merge 1 commit intoGui-Yom:masterfrom
Conversation
Author
|
@Gui-Yom, FYI, a Rust language team member has recently proposed to merge the aforementioned change to the language. Source: rust-lang/rust#135331 (comment). You can subscribe to the thread to get notified of further developments. |
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Aug 11, 2025
Reject relaxed bounds inside associated type bounds (ATB) **Reject** relaxed bounds — most notably `?Sized` — inside associated type bounds `TraitRef<AssocTy: …>`. This was previously accepted without warning despite being incorrect: ATBs are *not* a place where we perform *sized elaboration*, meaning `TraitRef<AssocTy: …>` does *not* elaborate to `TraitRef<AssocTy: Sized + …>` if `…` doesn't contain `?Sized`. Therefore `?Sized` is meaningless. In no other (stable) place do we (intentionally) allow relaxed bounds where we don't also perform sized elab, this is highly inconsistent and confusing! Another point of comparison: For the desugared `$SelfTy: TraitRef, $SelfTy::AssocTy: …` we don't do sized elab either (and thus also don't allow relaxed bounds). Moreover — as I've alluded to back in rust-lang#135841 (review) — some later validation steps only happen during sized elaboration during HIR ty lowering[^1]. Namely, rejecting duplicates (e.g., `?Trait + ?Trait`) and ensuring that `Trait` in `?Trait` is equal to `Sized`[^2]. As you can probably guess, on stable/master we don't run these checks for ATBs (so we allow even more nonsensical bounds like `Iterator<Item: ?Copy>` despite T-types's ruling established in the FCP'ed rust-lang#135841). This PR rectifies all of this. I cratered this back in 2025-01-10 with (allegedly) no regressions found ([report](rust-lang#135331 (comment)), [its analysis](rust-lang#135331 (comment))). [However a contributor manually found two occurrences](rust-lang#135229 (comment)) of `TraitRef<AssocTy: ?Sized>` in small hobby projects (presumably via GH code search). I immediately sent downstream PRs: Gui-Yom/turbo-metrics#14, ireina7/summon#1 (however, the owners have showed no reaction so far). I'm leaning towards banning these forms **without a FCW** because a FCW isn't worth the maintenance cost[^3]. Note that associated type bounds were stabilized in 1.79.0 (released 2024-06-13 which is 13 months ago), so the proliferation of ATBs shouldn't be that high yet. If you think we should do another crater run since the last one was 6 months ago, I'm fine with that. Fixes rust-lang#135229. [^1]: I consider this a flaw in the implementation and [I've already added a huge FIXME](https://github.com/rust-lang/rust/blob/82a02aefe07092c737c852daccebf49ca25507e3/compiler/rustc_hir_analysis/src/hir_ty_lowering/bounds.rs#L195-L207). [^2]: To be more precise, if the internal flag `-Zexperimental-default-bounds` is provided other "default traits" (needs internal feature `lang_items`) are permitted as well (cc closely related internal feature: `more_maybe_bounds`). [^3]: Having to track this and adding an entire lint whose remnants would remain in the code base forever (we never *fully* remove lints).
rust-timer
added a commit
to rust-lang/rust
that referenced
this pull request
Aug 11, 2025
Rollup merge of #135331 - fmease:ban-assoc-ty-unbounds, r=lcnr Reject relaxed bounds inside associated type bounds (ATB) **Reject** relaxed bounds — most notably `?Sized` — inside associated type bounds `TraitRef<AssocTy: …>`. This was previously accepted without warning despite being incorrect: ATBs are *not* a place where we perform *sized elaboration*, meaning `TraitRef<AssocTy: …>` does *not* elaborate to `TraitRef<AssocTy: Sized + …>` if `…` doesn't contain `?Sized`. Therefore `?Sized` is meaningless. In no other (stable) place do we (intentionally) allow relaxed bounds where we don't also perform sized elab, this is highly inconsistent and confusing! Another point of comparison: For the desugared `$SelfTy: TraitRef, $SelfTy::AssocTy: …` we don't do sized elab either (and thus also don't allow relaxed bounds). Moreover — as I've alluded to back in #135841 (review) — some later validation steps only happen during sized elaboration during HIR ty lowering[^1]. Namely, rejecting duplicates (e.g., `?Trait + ?Trait`) and ensuring that `Trait` in `?Trait` is equal to `Sized`[^2]. As you can probably guess, on stable/master we don't run these checks for ATBs (so we allow even more nonsensical bounds like `Iterator<Item: ?Copy>` despite T-types's ruling established in the FCP'ed #135841). This PR rectifies all of this. I cratered this back in 2025-01-10 with (allegedly) no regressions found ([report](#135331 (comment)), [its analysis](#135331 (comment))). [However a contributor manually found two occurrences](#135229 (comment)) of `TraitRef<AssocTy: ?Sized>` in small hobby projects (presumably via GH code search). I immediately sent downstream PRs: Gui-Yom/turbo-metrics#14, ireina7/summon#1 (however, the owners have showed no reaction so far). I'm leaning towards banning these forms **without a FCW** because a FCW isn't worth the maintenance cost[^3]. Note that associated type bounds were stabilized in 1.79.0 (released 2024-06-13 which is 13 months ago), so the proliferation of ATBs shouldn't be that high yet. If you think we should do another crater run since the last one was 6 months ago, I'm fine with that. Fixes #135229. [^1]: I consider this a flaw in the implementation and [I've already added a huge FIXME](https://github.com/rust-lang/rust/blob/82a02aefe07092c737c852daccebf49ca25507e3/compiler/rustc_hir_analysis/src/hir_ty_lowering/bounds.rs#L195-L207). [^2]: To be more precise, if the internal flag `-Zexperimental-default-bounds` is provided other "default traits" (needs internal feature `lang_items`) are permitted as well (cc closely related internal feature: `more_maybe_bounds`). [^3]: Having to track this and adding an entire lint whose remnants would remain in the code base forever (we never *fully* remove lints).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hello there 👋, I'm a member of the Rust compiler team.
?Sizedbounds in associated type bounds don't have any effect.Deref<Target: ?Sized>can simply be replaced withDerefwithout any change in semantics.If you look at the definition of trait
Deref, you can seetype Target: ?Sizedwhich states that<T as Deref>::Targetis not necessarilySizedby default for all typesT. Therefore a bound likeC: Derefimplies thatTargetis maybe-Sized. EvenC: Deref<Target: >(sic!) doesn't meanC: Deref<Target: Sized>just aswhere <C as Deref>::Target:(sic!) doesn't meanwhere <C as Deref>::Target: Sized.It's a bug in the current version of the Rust compiler that writing
Trait<Assoc: ?Sized>is allowed, it should've been forbidden all along. See also rust-lang/rust#135229.The compiler bug will likely be fixed soon. To avoid your crate from breaking in the future, I've removed the offending bounds.