Proposal link: swift-evolution/0095-any-as-existential.md at master · apple/swift-evolution · GitHub
Hello Swift Community,
The review of SE-0095: "Replace protocol<P1,P2> syntax with Any<P1,P2>" ran from May 24…30, 2016. The proposal is returned with revision requested - ideally the revised proposal will be included in Swift 3.
There was an incredible amount of feedback from the community, continuing even today. The principle problem identified by community about the proposal is that "Any<T1, T2>” implies very strongly an “any of T1 OR T2” relationship (aka disjunction) and not “any type conforming to T1 AND T2” relationship (aka conjunction). There was also some related discussion as to how the “Any<>” syntax aligns with future generalized existential syntax, much discussion as to whether it should be spelled Any<> or any<>, and some discussion about "angle bracket blindness".
The core team extensively discussed the feedback and considered many different possible paths forward. The conclusion of this is that it recommends that SE-0095 be revised into a fairly different proposal, one that introduces a new infix “&” type operator for representing protocol and other type compositions. Instead of:
func f(a : protocol<A, B>) {}
func g<T : A>(x : T) where T : B {} or func g<T : protocol<A, B>>(x : T) {}
You would instead write:
func f(a : A & B) {}
func g<T : A & B>(x : T) {}
The degenerate case of protocol<> needs an answer, but only for the definition of the Any typealias in the standard library, so it can be left out of the proposal.
The core team feels that this is an elegant solution for Swift 3 that conveys exactly the right intent. When generalized existentials are introduced, an elaborated syntax can be introduced to generalize this, e.g. "Any<A & B where … >” or “(T : A & B where …)” or whatever else makes sense in context of its design.
The principle concern with this is that having an “&" operator for generic constraints leads the question of whether the language should introduce an "|" operator to represent disjunctions in type constraints (something that the type system cannot and should not support). This is a topic that the C++ committee grappled with in its discussions of C++ concepts. That said, the core team feels that “&” directly expresses the relationship that we want, that “|” can be addressed in the “commonly rejected proposals" list, and that other proposals for an infix operator (like +) skirt this issue but are strictly worse at communicating intent in code.
Many thanks to Adrian Zubarev, Austin Zheng for driving this discussion!
-Chris Lattner
Review Manager