This was indeed a very thorough review by the core team. I'll prepare a v2 proposal with this feedback taken into account so we can continue moving things along.
One quick question - is making whatever syntax is chosen for Swift 3 "forward-compatible" with a future generalized existential feature a concern? Austin > On Jun 1, 2016, at 9:47 PM, Chris Lattner via swift-evolution > <[email protected]> wrote: > > 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
