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

Xiaodi Wu xiaodi.wu at gmail.com
Sun Feb 19 17:50:56 CST 2017

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/20170219/786ee7e0/attachment.html>

More information about the swift-evolution mailing list