Should associated type bounds on supertraits be implied?

[compiler-errors]

I tried this code:

#![feature(associated_type_bounds)]

trait Trait: Super<Assoc: Bound> {}

trait Super {
    type Assoc;
}

trait Bound {}

fn foo<T>(x: T) where T: Trait {}

And this happened:

error[E0277]: the trait bound `<T as Super>::Assoc: Bound` is not satisfied
  --> src/lib.rs:13:8
   |
13 |     T: Trait,
   |        ^^^^^ the trait `Bound` is not implemented for `<T as Super>::Assoc`
   |
note: required by a bound in `Trait`
  --> src/lib.rs:3:27
   |
3  | trait Trait: Super<Assoc: Bound> {}
   |                           ^^^^^ required by this bound in `Trait`
help: consider further restricting the associated type
   |
13 |     T: Trait, <T as Super>::Assoc: Bound
   |             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

For more information about this error, try `rustc --explain E0277`.

I'm not exactly sure whether this should be implied or not! Nominating this for T-lang for discussion, I'd like to know whether this is expected behavior or not.

Argument for the code failing

For non trait aliases, we don't imply currently any where clauses for non-supertrait bounds. In this case, supertrait bounds are precisely trait and associated type bounds which have Self as their self type. Since we can interpret Self: Super<Assoc: Bound> as two bounds -- Self: Super and <Self as Super>::Assoc: Bound -- it's consistent why the latter is not implied.

Fixing this complicates the code even more.

Argument for the code compiling

The concept of "supertraits" from a language perspective (and not a types perspective) is not very well specified -- one may argue again that it could mean anything that comes after the colon in trait Trait: ... or Self: ..., for example. Whether or not that's more intuitive, 🤷

It's also just annoying that this doesn't compile, and who knows if associated type bounds (which I'm personally motivated to compile) becomes more frustrating and/or less useful without these bounds being implied.

---

Related to #112568, which is essentially the same question but for return type notation.

[fmease]

#110512 may also provide some additional background information.

(Not that I have any say in this but I found implying the assoc type bounds on super traits quite useful and intuitive. In a project of mine, https://github.com/fmease/lushui, I used to make use of this until the aforementioned PR removed them. I had to enable & use trait aliases to achieve the same level of conciseness)

[compiler-errors]

Sorry about that @fmease 😆 -- #110512 was intended to fix pretty bad ICEs with the associated-type-bounds feature, and it intentionally regressed the code which is given in my examples above because I didn't really want to take a firm stance on the question above.

[tmandry]

The RFC for associated type bounds chose a particular desugaring when they are used in associated types to so that they would have "implied bounds" behavior, so that's evidence that this kind of behavior is desired.

We also have the RFC for full implied bounds which is further evidence that it's desired, and I think the question then becomes whether we want to stabilize this before all of implied bounds.

@compiler-errors My understanding is that general implied bounds is blocked behind implementation feasibility, and it seems we don't have those same issues with this feature, correct?

[compiler-errors]

What an interesting desugaring... Desugaring to an anonymous associated type when an associated type bound is used in an associated type's item bounds position seems way overkill, lol.

Anyways, okay, I can put up a draft PR with this implied bounds behavior. It does seem like it's what's desired from the RFC.