> On Jun 2, 2016, at 10:14 AM, Thorsten Seitz via swift-evolution > <[email protected]> wrote: > > > > Am 02.06.2016 um 07:42 schrieb Austin Zheng via swift-evolution > <[email protected] <mailto:[email protected]>>: > >> Excellent. >> >> I put together a PR with a revised proposal containing the core team's >> recommended approach. If anyone is curious they can see it here: >> https://github.com/austinzheng/swift-evolution/blob/ef6adbe0fe09bff6c44c6aa9d73ee407629235ce/proposals/0095-any-as-existential.md >> >> <https://github.com/austinzheng/swift-evolution/blob/ef6adbe0fe09bff6c44c6aa9d73ee407629235ce/proposals/0095-any-as-existential.md> >> >> Since this is the de-facto second round discussion thread, I'll start with >> my personal opinion (which is *not* reflected in the PR): the '&' separators >> in lieu of commas are a good idea, but I would still prefer the types to be >> wrapped in "Any<>", at least when being used as existentials. > > I'm very happy with using `&` as I find this very readable. > I would prefer not having to wrap them into `Any<>`. While I can image > `Any<>`, or rather `any<>`, for existentials with `where` clauses, I would > absolutely hate having to wrap all existentials into that which would > introduce a lot of noise. > >> >> My reasons: >> >> - Jordan Rose brought up a good point in one of the discussion threads >> today: a resilience goal is to allow a library to add an associated type to >> a protocol that had none and not have it break user code. If this is true >> whatever syntax is used for existentials in Swift 3 should be a valid subset >> of the generalized existential syntax used to describe protocol compositions >> with no associated types. > > If `P` is an existential there is no problem either, isn't it? No need to > require `Any<P>`. > > > >> >> - I would rather have "Any<>" be used consistently across all existential >> types eventually than have it only be used for (e.g.) existential types with >> `where` constraints, or allowing two different representations of the same >> existential type (one with Any, and one without). > > Far too much noise! > > >> >> - I think any generalized existential syntax without delimiting markers >> (like angle braces) is harder to read than syntax with such markers, so I >> would prefer a design with those markers. > > I think markers are only needed if a `where` clause is present and probably > not even then.
The only reason to require them generally is if they are required for disambiguation in specific syntactic positions and it would be too confusing to remember where parentheses are required. If that isn’t the case they should not be required. It would be interesting to hear from someone closer to the grammar about whether an enclosing syntactic context would ever be required for disambiguation or not. If we don’t require them, parentheses can still be used for clarity when desired. > > -Thorsten > > >> >> Best, >> Austin >> >>> On Jun 1, 2016, at 10:17 PM, Chris Lattner <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>>> On Jun 1, 2016, at 9:53 PM, Austin Zheng <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> 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? >>> >>> Yes it is a concern, but we assume that the “X & Y” syntax will always be >>> accepted going forward, as sugar for the more general feature that is yet >>> to be designed. >>> >>> -Chris >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
