Description
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 > = 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<T> = <T as Trait>::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
Bonus points if when : Sized is a supertrait of T, the ?Sized + ends up not being required to prevent the lint from firing.