Update NNNN-unlock-existential-types-for-all-protocols.md

proposals/NNNN-unlock-existential-types-for-all-protocols.md

@@ -77,7 +77,7 @@ The current semantic inconsistency also discourages authors from refining their
 
 Removing the type-level restriction would mean that adding defaulted requirements to a protocol is always both a binary- and source-compatible change, since it could no longer interfere with existing uses of the protocol.
 
-### Type-erasing Wrappers
+### Type-Erasing Wrappers
 
 Beyond making incremental progress toward the goal of [generalized existentials](https://github.com/apple/swift/blob/main/docs/GenericsManifesto.md#generalized-existentials), removing this restriction is a necessary — albeit not sufficient — condition for eliminating the need for manual type-erasing wrappers like [`AnySequence`](https://developer.apple.com/documentation/swift/anysequence). These containers are not always straightforwand to implement, and can become a pain to mantain in resilient environments, since the wrapper must evolve in parallel to the protocol. In the meantime, wrapping the unconstrained existential type instead of resorting to `Any` or boxing the value in a subclass or closure will enable type-erasing containers to be written in a way that's easier for the compiler to optimize, and ABI-compatible with future generalized existentials. For requirements that cannot be accessed on the existential directly, it will be possible to forward the call through the convolution of writing protocol extension methods to open the value inside and have full access to the protocol interface inside the protocol extension:
 
@@ -149,12 +149,12 @@ ___
 This way, a protocol or protocol extension member (method/property/subscript/initializer) may be used on an existential value iff the following criteria hold:
 * The type of the invoked member (accessor — for storage declarations), as viewed in context of the *base type*, must **not** contain references to `Self` or `Self`-rooted associated types in [non-covariant](https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)) position.
 
-> The "`isAvailableOnExistential`" routine will consider the following types covariant:
+> The following types will be considered covariant:
 > * Function types in their result type.
 > * Tuple types in either of their element types.
-> * Swift.Optional in its `Wrapped` type.
-> * Swift.Array in its `Element` type.
-> * Swift.Dictionary in its `Value` type.
+> * [Swift.Optional](https://developer.apple.com/documentation/swift/optional) in its `Wrapped` type.
+> * [Swift.Array](https://developer.apple.com/documentation/swift/array) in its `Element` type.
+> * [Swift.Dictionary](https://developer.apple.com/documentation/swift/dictionary) in its `Value` type.
 
 ## Detailed Design
 
@@ -212,6 +212,7 @@ protocol P {
 
   func method() -> B
 }
+
 protocol Q: P where B == G<A> {}
 ```
 Notice how the associated type that would preclude a call to `method` on a value of type `Q` is actually `A`, not `B` as the result type may suggest, due to the same-type constraint on the protocol.