Reduce the number of constraints repeated when writing T: SomeTrait

[sgrif]

Rendered

[nikomatsakis]

There is a rustc bug on this issue as well:

rust-lang/rust#20671

I am generally in favor of this change. I have to give the RFC a detailed read. I am not sure if there are backwards compatibility concerns -- if so I would expect them to arise only in corner cases, but still worth considering.

[durka]

Why leave the several exceptions where supertrait bounds would not be inherited? It seems less confusing to inherit everything.

In particular I don't understand the difference between Vec<Self>: Bar and Result<Self, T>: Bar.

[soltanmm]

When it says that Self appearing in the target means that the constraint will be inherited (elaborated?), does that include associated type projections (e.g. Self::Foo: Trait)? Either way, could that be explicitly mentioned?
EDIT: More specifically:

trait A {
    type Foo: X;
}
trait B: A where <Self as A>::Foo: Y {}

Would claiming Bar: B elaborate to Bar::Foo: Y?
EDIT EDIT:
And and and extending off of @durka, elaborating everything would allow the derive macros to do the right thing w.r.t. associated types and type parameters in struct members by just requiring pointwise implementations of the actual member types instead of today's weird undescribable horro- I mean approximation.

[aturon]

@nikomatsakis Any thoughts on this? Are you inclined to subsume this under a more general implied bounds RFC? Can we mentor someone to write that?

[nikomatsakis]

I am going to close this RFC in favor of #2089, which proposes a more general variant of the design described in here! But please, @sgrif or others, let me know if you see anything that this RFC covered that #2089 does not!