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

Matthew Johnson matthew at anandabits.com
Thu Jun 2 08:17:00 CDT 2016



Sent from my iPad

> On Jun 2, 2016, at 12:42 AM, Austin Zheng via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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.

Thanks for writing up the revision Austin, especially since it does not reflect your own opinion.

My opinion is that we should view these as type expressions.  We don't require any kind of delimiters around value expressions, allowing optional parentheses for clarification and as a matter of style.  I don't see any reason to treat type expressions any different than that syntactically.  

> 
> 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.
> 
> - 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).
> 
> - 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.
> 
> Best,
> Austin
> 
>>> On Jun 1, 2016, at 10:17 PM, Chris Lattner <clattner at apple.com> wrote:
>>> 
>>> 
>>> On Jun 1, 2016, at 9:53 PM, Austin Zheng <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
> 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/03547119/attachment.html>


More information about the swift-evolution mailing list