I'm sure the list is getting sick of me making this point over and over again :), so I'll only do it one more time: I find the lack of delimiters far worse in terms of readability for type expressions of any appreciable complexity than any number of `Any<>` tokens. In fact, I'm a bit surprised the core team decided to go in this direction, given their stance on parentheses for function types, and replacing operators like "&&" or "||" with "and" or "or". I respect their decision, though.
On 6/2/16, Thorsten Seitz <[email protected]> wrote: > > >> Am 02.06.2016 um 07:42 schrieb Austin Zheng via swift-evolution >> <[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 >> >> 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. > > -Thorsten > > >> >> Best, >> Austin >> >>>> On Jun 1, 2016, at 10:17 PM, Chris Lattner <[email protected]> wrote: >>>> >>>> >>>> On Jun 1, 2016, at 9:53 PM, Austin Zheng <[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] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
