Proposal link:
https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md
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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
