[swift-evolution] [Returned for Revision] SE-0095: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Matthew Johnson]

> On Jun 2, 2016, at 10:14 AM, Thorsten Seitz via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 
> Am 02.06.2016 um 07:42 schrieb Austin Zheng via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
> 
>> 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 <clattner at apple.com <mailto:clattner at apple.com>> wrote:
>>> 
>>> 
>>>> On Jun 1, 2016, at 9:53 PM, Austin Zheng <austinzheng at gmail.com <mailto:austinzheng at gmail.com>> 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
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160602/bc1b49d8/attachment.html>