Draft 2

Author: kavon

proposals/NNNN-suppressed-associated-types.md

@@ -187,6 +187,8 @@ after building the declaration's generic signature, if there was an inverse
 requirement `Thing: ~IP` and yet `Thing` must conform to `IP` anyway, then the 
 inverse requirement is diagnosed as invalid.
 
+### Limits of Suppression
+
 Default requirements become fixed once the generic signature is built for that
 declaration, after applying the expansion procedure. For example,
 
@@ -218,6 +220,43 @@ inverse requirement `Val.Element: ~Copyable` without mutating the generic
 signature of `Stack`, which is not permitted, so the inverse requirement is 
 illegally scoped in `push`.
 
+The same concept applies to the requirement signatures of a protocol becoming
+fixed after expansion is applied to it locally. Consider this protocol `P`,
+
+```swift
+protocol P<A>: ~Copyable { 
+  associatedtype A: ~Copyable
+}
+```
+
+Its requirement signature is `<Self where Self : Escapable, Self.A : Escapable>`,
+because the default `Copyable` requirements were suppressed on both `Self` and
+`Self.A`. Next, consider this protocol `Q`,
+
+```swift
+protocol Q<B>: ~Copyable { 
+  associatedtype B: ~Copyable, P
+}
+```
+
+The expansion procedure applies locally to `Q` as follows. 
+The desugared requirement `Self.B: P` implies `Self.B.A: Copyable`, yielding the now-fixed requirement signature:
+
+```
+<Self where Self : Escapable, Self.B : P, Self.B.A : Copyable>
+                                          ~~~~~~~~~~~~~~~~~~~
+                                          from expansion procedure
+```
+
+Constraining a generic type parameter `T` to conform to `Q` only permits suppression of a default inferred for `T.B`, not `T.B.A`:
+
+```swift
+func limits<T: Q>(_ t: T) 
+  where T.B: ~Copyable, 
+        T.B.A: ~Copyable // error: T.B.A is required to be Copyable
+        {}
+```
+
 Inverses can apply across equality constraints _within the same declaration's generic signature_
 to cancel-out default requirements from primary associated types. Consider this example,
 
@@ -417,17 +456,20 @@ func ex2<R: ~Copyable>(_ s: any Source<R>) {
 
 ### Recursion
 
-Protocol requirements can be such that an infinite number of associated types
-are derivable from a type conforming to that protocol. A classic example is,
+There can be an infinite number of type parameters derivable from a conformance
+requirement, because a protocol's associated type requirement can be part of a cycle with the protocol itself:
 
 ```swift
 protocol P<A>: ~Copyable {
   associatedtype A: ~Copyable, P
 }
 ```
 
-For a generic environment `<R where R: P>`, all of `R.A, R.A.A, R.A.A.A, ...`,
-are Copyable because the type with one fewer `A` conforms to `P`. 
+For a generic signature `<R where R: P>`, all of the type parameters 
+`R.A, R.A.A, R.A.A.A, ...`,
+are Copyable. 
+For any type parameter `X` rooted in `R`, the type `X.A` conforms to `P`, and by the expansion procedure, that implies `X.A: Copyable` because `A` is a primary
+associated type of `P`.
 
 Next, consider this pair of mutually recursive protocols where only one of 
 them has a primary associated type,
@@ -442,25 +484,21 @@ protocol Second: ~Copyable {
 }
 ```
 
-For a generic environment `<T where T: First>`, we observe that any archetype
-rooted in `T` and ending with an `A`, such `T.A.B.A`, is Copyable because 
-`T.A.B: First` and `First` has a primary associated type `A`. 
-Similarly, for an archetype that ends in a `B`, it is not Copyable, because
-`T.*.A: Second` which has only the ordinary associated type `B`. So we get an
-alternating pattern for the defaults,
+For a generic signature `<T where T: First>`, we observe that any type parameter
+rooted in T and ending with an A, such T.A.B.A, is Copyable because 
+`T.A.B: First` and First has a primary associated type A. 
+Similarly, for type parameter T.A.B which ends in a B, it is *not* required to conform to Copyable, because `T.A: Second` and Second has only
+the non-primary associated type B. So there is an alternating pattern for the 
+defaults,
 
 ```
 T.A : Copyable
-T.B : ~Copyable
-T.B.A: Copyable
-T.B.A.B: ~Copyable
-T.B.A.B.A: Copyable
+T.A.B: ~Copyable
+T.A.B.A: Copyable
+T.A.B.A.B: ~Copyable
 ...
 ```
 
-The proof by induction is left as an exercise for the reader.
-
-
 ### Default Witnesses
 
 An associated type can already declare a default _witness_, which is a type that
@@ -583,12 +621,13 @@ may now suppress conformance to these protocols, a conditional
 conformance to `Copyable` or `Escapable` that depends on an
 associated type is still not allowed:
 ```swift
-struct QueueHolder<Q: Queue>: ~Copyable {}
-extension QueueHolder: Copyable where Q.Element: Copyable {}  // error
+protocol Goose: ~Copyable { associatedtype Quack: ~Copyable }
+struct Pond<G: Goose>: ~Copyable {}
+extension QueueHolder: Copyable where G.Quack: Copyable {}  // error
 ```
-This restriction is for runtime implementation reasons.
+This restriction is for runtime implementation limitations.
 
-<!-- TODO: Perhaps this needs elaboration? -->
+<!-- TODO: Perhaps the limitation needs elaboration? -->
 
 
 ## Source Compatibility
@@ -635,8 +674,24 @@ assumption is no longer true.
 The ABI of existing code is not affected by this proposal.
 
 On the other hand, changing an associated type declaration in an library
-to suppress conformance is an ABI-breaking change, for similar reasons
-to those described above.
+to suppress conformance is can be an ABI-breaking change. For example, an
+extension of a protocol providing a default implementation could have its symbol
+name change, as these two implementations of `greet` must have distinct names:
+
+```swift
+protocol Greeter<T> {
+  associatedtype T: ~Copyable
+  func greet()
+}
+
+extension Greeter {
+  func greet() { print("hello")}
+}
+
+extension Greeter where T: ~Copyable {
+  func greet() { print("سلام") }
+}
+```
 
 ## Future Directions
 
@@ -660,10 +715,25 @@ constrained existential via `any Q<some ~Copyable>`.
 
 ## Alternatives Considered
 
+Through the development of this proposal, various alternate formulations were considered.
+
 ### No recursion
 
-A prior version of this proposal [was pitched](https://forums.swift.org/t/pitch-suppressed-default-conformances-on-associated-types/81880) that was absent of any defaulting behavior
-for associated types.
+A prior version of this proposal [was pitched](https://forums.swift.org/t/pitch-suppressed-default-conformances-on-associated-types/81880) that was absent of any defaulting behavior for associated types. The primary fault was that it
+provided an inconsistent behavior when compared with generic types like S:
+
+```swift
+struct S<T: ~Copyable>: ~Copyable {}
+
+protocol P<T>: ~Copyable {
+  associatedtype T: ~Copyable
+}
+
+extension S {} // T: Copyable
+extension P {} // T: ~Copyable
+```
+
+Only the extension for S provides a default for its T.
 
 ### Definition-driven associated type defaults