Lint `type_alias_bounds` fires unnecessarily for trait bounds that define short-hand projections on the RHS · Issue #125709 · rust-lang/rust (original) (raw)

Code

trait Trait { type Assoc; }

type AssocOf<T : ?Sized + Trait> = T::Assoc;

Current output

warning: bounds on generic parameters are not enforced in type aliases --> src/lib.rs:3:18 | 3 | type AssocOf<T : ?Sized + Trait> = T::Assoc; | ^^^^^^ ^^^^^ | help: use fully disambiguated paths (i.e., <T as Trait>::Assoc) to refer to associated types in type aliases --> src/lib.rs:3:36 | 3 | type AssocOf<T : ?Sized + Trait> = T::Assoc; | ^^^^^^^^ = note: #[warn(type_alias_bounds)] on by default help: the bound will not be checked when the type alias is used, and should be removed | 3 - type AssocOf<T : ?Sized + Trait> = T::Assoc; 3 + type AssocOf = T::Assoc; |

Desired output

No warning whatsoever

Rationale and extra context

Whilst it is true that left-hand-side bounds on generic parameters are not enforced in type aliases, { performing a Trait associated type "lookup" on / resolving the Trait associated type of } a given type T does effectively constrain T to be : ?Sized + Trait.

This means that for that specific snippet, the pattern is fine, both presently, and in the future, should these bounds end up enforced.

Whilst it may look like an oddly over-specific example, it is actually a common pattern to define a type alias as a shortcut for a trait associated type lookup.

Granted, the bounds could be skipped, like so:

type AssocOf<T : ?Sized + Trait> = T::Assoc;

type AssocOf = ::Assoc;

but this significantly hinders the quality of the generated documentation (now people need to look at the implementation/"value" of the type alias to try and figure out what the bounds on it are).

Other cases