Update to account for associated types.

Author: nikomatsakis

text/0000-no-unused-impl-parameters.md

@@ -4,16 +4,23 @@
 
 # Summary
 
-Disallow impls from having type parameters that do not appear in
-either the trait reference or the self type of the impl.
+Disallow unconstrained type parameters from impls. In practice this
+means that every type parameter must either:
+
+1. appear in the trait reference of the impl, if any;
+2. appear in the self type of the impl; or,
+3. be bound as an associated type.
+
+This is an informal description, see below for full details.
 
 # Motivation
 
 Today it is legal to have impls with type parameters that are
 effectively unconstrainted. This RFC proses to make these illegal by
 requiring that all impl type parameters must appear in either the self
 type of the impl or, if the impl is a trait impl, an (input) type
-parameter of the trait reference.
+parameter of the trait reference. Type parameters can also be constrained
+by associated types.
 
 There are many reasons to make this change. First, impls are not
 explicitly instantiated or named, so there is no way for users to
@@ -81,15 +88,61 @@ impl<A,B:Default> Foo<A> {
         B::Default
     }
 }
+
+// Legal: `U` does not appear in the input types,
+// but it bound as an associated type of `T`.
+impl<T,U> Foo for T
+    where T : Bar<Out=U> {
+}
 ```
 
 # Detailed design
 
-Require that every impl type parameter appears textually within the
-input type parameters of the trait reference or the impl self
-type. Even if we introduce variance in the future, this is sufficient
-to ensure that the type parameter is constrained modulo lifetimes;
-lifetimes are not taken into account when selecting traits.
+Type parameters are legal if they are "constrained" according to the
+following inference rules:
+
+```
+If T appears in the impl trait reference,
+  then: T is constrained
+
+If T appears in the impl self type,
+  then: T is constrained
+
+If <T0 as Trait<T1...Tn>>::U == V appears in the impl predicates,
+  and T0...Tn are constrained
+  and T0 as Trait<T1...Tn> is not the impl trait reference
+  then: V is constrained
+```
+
+The interesting rule is of course the final one. It says that type
+parameters whose value is determined by an associated type reference
+are legal. A simple example is:
+
+```
+impl<T,U> Foo for T
+    where T : Bar<Out=U>
+```
+
+However, we have to be careful to avoid cases where the associated
+type is an associated type of things that are not themselves
+constrained:
+
+```
+impl<T,U,V> Foo for T
+    where U: Bar<Out=V>
+```
+
+Similarly, the final clause in the rule aims to prevent an impl from
+"self-referentially" constraining an output type parameter:
+
+```
+impl<T,U> Bar for T
+    where T : Bar<Out=U>
+```
+
+This last case isn't that important because impls like this, when
+used, tend to result in overflow in the compiler, but it's more
+user-friendly to report an error earlier.
 
 # Drawbacks
 
@@ -112,7 +165,4 @@ approach rules out the possibility of impl specialization.
 
 # Unresolved questions
 
-I am not 100% certain whether it is safe to permit impl type
-parameters that only appear in associated types of impls. I am working
-through this in the meantime, but for now it seems safer to simply be
-restrictive.
+None.