Support the `Trait<Output=Type>` syntax

[nikomatsakis]

Today when we expand associated types we always expand to a fresh type parameter. Per the RFC we should support a syntax like:

Trait<Output=Type>

to permit a trait reference that specifies what to expand an associated type into. This is a subset of full == references.

Note that cyclic equality does not have to be supported (though it'd be nice if it at least produced a nice error message, not an ICE):

fn foo<T:Something<Out=U::Out>, U:Something<Out=T::Out>>() { ... }

[nrc]

To clarify the specification here, there are two ways to use an equality bound (afaiui) - in where clauses and as a type parameter. E.g.,

trait Foo {
    type A;
}

struct Bar;

fn foo<I: Foo<A=Bar>>(x: &I) {}

fn foo<I>(x: &I)
    where I: Foo,
          I::A = Bar
{
}

The two definitions of foo are equivalent.

[nrc]

The 'parameter' form also allows such bounds on trait objects, e.g., &Foo<A=Bar>.

[nikomatsakis]

Yes, though this issue is specific to the Foo=Bar form, which avoids some complexities that the other form admits. (In particular, things like fn foo<A,B>() where A = B). You could (I guess) support a limited form of constraints like X::E = Y (though note that X::E is not legal syntax yet; supporting that is a separate issue).

[nrc]

@nikomatsakis clarifying: the two forms you are discussing are A=Foo and I::A=Foo? Both in where clauses (the <A=Foo> form being sugar for where I::A=Foo). Or are you suggesting only implementing the <A=Foo> form and not any equality constraint inwhere clauses?

[nikomatsakis]

@nick29581 sorry, missed that message, I was suggesting only implementing A=Foo and not any equality constraints, since it is more general (works for object types) and covers only the range of constraints we want, but I have no objection to doing more. Anyway, I see you have a PR now, so I guess this is moot.