Update 'any' proposal based on feedback from the pitch discussion.

Author: hborla

proposals/NNNN-existential-any.md

@@ -10,6 +10,8 @@
 
 Existential types in Swift have an extremely lightweight spelling: a plain protocol name in type context means an existential type. Over the years, this has risen to the level of **active harm** by causing confusion, leading programmers down the wrong path that often requires them to re-write code once they hit a fundamental [limitation of value-level abstraction](https://forums.swift.org/t/improving-the-ui-of-generics/22814#heading--limits-of-existentials). This proposal makes the impact of existential types explicit in the language by annotating such types with `any`.
 
+Swift evolution discussion thread: [[Pitch] Introduce existential `any`](https://forums.swift.org/t/pitch-introduce-existential-any/53520).
+
 ## Motivation
 
 Existential types in Swift have significant limitations and performance implications. Some of their limitations are missing language features, but many are fundamental to their type-erasing semantics. For example, given a protocol with associated type requirements, the existential type cannot conform to the protocol itself without a manual conformance implementation, because there is not an obvious concrete associated type that works for any value conforming to the protocol, as shown by the following example:
@@ -51,7 +53,7 @@ existential-type -> 'any' type
 
 ### Semantics of explicit existential types
 
-The semantics of `any` types are the same as existential types today. Explicit `any` can only be applied to protocols and protocol compositions; `any` cannot be applied to nominal types, structural types, and type parameters:
+The semantics of `any` types are the same as existential types today. Explicit `any` can only be applied to protocols and protocol compositions, or existential metatypes thereof; `any` cannot be applied to nominal types, structural types, type parameters, and protocol metatypes:
 
 ```swift
 struct S {}
@@ -61,33 +63,52 @@ let s: any S = S() // error: 'any' has no effect on concrete type 'S'
 func generic<T>(t: T) {
   let x: any T = t // error: 'any' has no effect on type parameter 'T'
 }
+
+let f: any ((Int) -> Void) = generic // error: 'any' has no effect on concrete type '(Int) -> Void'
 ```
 
-`any` also cannot be applied to `Any` and `AnyObject` (unless part of a protocol composition).
+`any` is unnecessary for `Any` and `AnyObject` (unless part of a protocol composition):
+
+```swift
+struct S {}
+class C {}
 
+let value: any Any = S() // warning: 'any' is redundant on type 'Any'
+let values: [any Any] = [] // warning: 'any' is redundant on type 'Any'
+let object: any AnyObject = C() // warning: 'any' is redundant on type 'AnyObject'
 
-> Rationale: `any Any` and `any AnyObject` are redundant. `Any` and `AnyObject` are already special types in the language, and their existence isn’t nearly as harmful as existential types for regular protocols because the type-erasing semantics is already explicit in the name.
+protocol P {}
+extension C: P {}
 
+let pObject: any AnyObject & P = C() // okay
+```
 
-The existential metatype becomes `(any P).Type`, and the protocol metatype remains `P.Protocol`.
+> **Rationale**: `any Any` and `any AnyObject` are redundant. `Any` and `AnyObject` are already special types in the language, and their existence isn’t nearly as harmful as existential types for regular protocols because the type-erasing semantics is already explicit in the name.
 
-Examples
+The existential metatype, i.e. `P.Type`, becomes `any P.Type`:
 
 ```swift
 protocol P {}
-class C {}
+struct S: P {}
+
+let existentialMetatype: any P.Type = S.self
 
-any P
-any Any           // error
-any AnyObject     // error
-any P & AnyObject
-any C             // error
-any P & C
-any () -> Void    // error
+protocol Q {}
+extension S: Q {}
 
-(any P).Type
+let compositionMetatype: any (P & Q).Type = S.self
+```
+
+> **Rationale**: The existential metatype erases the underlying concrete metatype and allows access to static protocol requirements. The spelling `(any P).Type` could easily be confused with the metatype of the existential type itself (also called the "protocol metatype"), i.e. the type of `(any P).self`. This value does _not_ have a concrete underlying conforming type through which to invoke static protocol requirements. The spelling `any P.Type` is less likely to cause this confusion, it enforces the notion that the existential metatype is also a form of existential type with type-erasing semantics, and it introduces more syntactic distance between the existential metatype and the protocol metatype.
+
+The protocol metatype and its value, i.e. `P.Protocol` and `P.self`, become `(any P).Protocol` and `(any P).self`, respectively:
+
+```swift
+protocol P {}
 
-func test<T>(_: T) where T == any P
+let protocolMetatype: (any P).Protocol = (any P).self
+let invalidMetatype: (any P).Type = (any P).self // error: metatype of 'any P' is spelled with '.Protocol'
+let invalidProtocolMetatype: any P.Protocol = (any P).self // error: protocol metatype is spelled '(any P).Protocol'
 ```
 
 ## Source compatibility
@@ -109,8 +130,17 @@ None.
 
 ## Alternatives considered
 
+### Rename `Any` and `AnyObject`
+
 Instead of leaving `Any` and `AnyObject` in their existing spelling, an alternative is to spell these types as `any Value` and `any Object`, respectively. Though this is more consistent with the rest of the proposal, this change would have an even bigger source compatibility impact. Given that `Any` and `AnyObject` aren’t as harmful as other existential types, changing the spelling isn’t worth the churn.
 
+### Use `Any<P>` instead of `any P`
+
+A common suggestion is to spell existential types with angle brackets on `Any`, e.g. `Any<Hashable>`. However, this syntax is misleading because it appears that `Any` is a generic type, which is confusing to the mental model for 2 reasons:
+
+1. A generic type is something programmers can implement themselves. In reality, existential types are a built-in language feature that would be _very_ difficult to replicate with regular Swift code.
+2. This syntax creates the misconception that the underlying concrete type is a generic argument to `Any` that is preserved statically in the existential type. The `P` in `Any<P>` looks like an implicit type parameter with a conformance requirement, but it's not; the underlying type confoming to `P` is erased at compile-time.
+
 ## Future Directions
 
 ### Extending existential types