[swift-evolution] [Draft] open and public protocols

[Adrian Zubarev]

I don’t see it, can you elaborate a whole proposal first, otherwise I’m not convinced. Why?

-- 
Adrian Zubarev
Sent with Airmail

Am 20. Februar 2017 um 00:51:18, Xiaodi Wu (xiaodi.wu at gmail.com) schrieb:

On Sun, Feb 19, 2017 at 5:26 PM, Adrian Zubarev <adrian.zubarev at devandartist.com> wrote:
Indeed, I have run into the same issue with this and have a proposal idea saved up regarding anonymous enum cases and subtyping relationships. It would not have been in-scope for phase 1, so I did not write to the list about it. I’m short on time these days, but eventually I’ll propose it unless someone else gets to it first. However, this problem does not justify open vs. public.

Why is an anonymous enum case justifying the problem over a closed protocol?

It's justified because enums are (according to the Swift core team) Swift's sum type. That is, when you want something to be "either X or Y" (or "one of X, Y, Z, or A"), enums are intended to provide all the facilities necessary to express that concisely and with the greatest ease. As you recall from discussion about union types, the core team has said that in circumstances where that goal is not met (clearly, here), they welcome proposals to improve enums so that they serve that use case. That is why anonymous enum cases (or some other design to improve the experience of using enums as a type for "either X or Y") is justified.

Can an anonymous enum case solve every problem a closed protocol can?

Perhaps, perhaps not. The point is that you proposed a use case purportedly to motivate closed protocols, and I am saying that it is insufficient to justify closed protocols because the core team has already stated that enums are intended to enable that use case. So it is up to you, if you wish to promote this idea, to come up with one or more compelling use cases and not for me or others to enumerate every use case for them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170220/99917ee7/attachment.html>