Redundant specification of associated types with bound by inheriting trait

[dhardy]

Given traits:

trait A {
    type X;
}
trait C: A<X = u32> {}

the compiler does enforce that types implementing C have the required type for X, yet claims the associated type must still be specified when used (e.g. in &C).

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=50ed977d59b2b0ab67effef5c84d810a

---

I would expect that it would be unnecessary (or even illegal) to specify the type of X twice hence consider this a bug. This limits API design: a trait like C cannot retroactively have a base trait with associated type like A added, and in any case requiring all users to write C<X = u32> or equivalent is undesirable.

Possibly such a change warrants an RFC, though since the extra type specification is redundant, not requiring it is not a breaking change. Making this change would however mean that an API cannot relax a constraint like X = u32 without the change being breaking (if a library uses trait C: A<X = u32> in its API but envisages switching to trait C: A in the future — seems unlikely).

[Centril]

Seems like this would fall out of rust-lang/rfcs#1672?

[dhardy]

Not sure; that seems to be mostly about mutually exclusive trait implementations. This is about forwarding a required bound.

[dhardy]

This works on the latest stable, so we can close this.