@slavapestov loosened these restrictions as part of supporting extensions of concrete types, e.g.,:

extension Array where Element == String { ... }

It's plausible that we could reject some instances of this, but I'm not sure that we should. Rather, we need to finish fixing `Substitution::subst` et al.

OK. We could still perhaps warn or error on a type or function declaration that introduces type variables that are always redundant, though with constrained extensions I guess we'd still end up having to digest this kind of generic signature downstream.

Yeah, and I've seen some cases of developers doing this simply so they have a shorter name for `T.AssocType1.AssocType2` to use in their signature.

Another legit use case I encountered while investigating emaloney (JIRA User)'s project is this kind of thing:

class Foo<T, U: P> where U.V == SomeGeneric<T, Int>

where the type parameter T is always determined by U.V, but the intent is to require U.V to be a parameterization of SomeGeneric.

Hi Joe,

I fixed a couple of issues here:

• slavapestov@edadba7

• slavapestov@623755d

Do you have any test cases for this problem? No doubt there are problems remaining but I don't have any concrete repros.

Closing this – if we get more test cases that fail, we can file more specific bugs.