Revise SE-0491 with carveout for generic params (#2970)

During the review, Slava Pestov explained that it didn’t make sense to try to apply a module selector to a member type whose base was a generic parameter, as the member type will always represent the union of all associated types by that name. Edit the proposal to specify that module selectors are not valid in this position.

Author: beccadax

proposals/0491-module-selectors.md

@@ -476,6 +476,28 @@ some other language feature has ruled out. For example, if a declaration is
 inaccessible because of access control or hasn't been imported into the current
 source file, a module selector will not allow it to be accessed.
 
+#### Member types of type parameters
+
+A member type of a type parameter must not be qualified by a module selector.
+
+```swift
+func fn<T: Identifiable>(_: T) where T.Swift::ID == Int {    // not allowed
+    ...
+}
+```
+
+This is because, when a generic parameter conforms to two protocols that have
+associated types with the same name, the member type actually refers to *both*
+of those associated types. It doesn't make sense to use a module name to select
+one associated type or the other--it will always encompass both of them.
+
+(In some cases, a type parameter's member type might end up referring to a 
+concrete type—typically a typealias in a protocol extension–which
+theoretically *could* be disambiguated in this way. However, in these
+situations you could always use the protocol instead of the generic parameter
+as the base (and apply a module selector to it if needed), so we've chosen not
+to make an exception for them.)
+
 ## Source compatibility
 
 This change is purely additive; it only affects the behavior of code which uses