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

Xiaodi Wu xiaodi.wu at gmail.com
Sun Feb 19 17:57:34 CST 2017


On Sun, Feb 19, 2017 at 5:55 PM, Adrian Zubarev <
adrian.zubarev at devandartist.com> wrote:

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

I'm sorry. I'm not sure what you mean. Can you clarify what you'd like to
be more convinced of?


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


More information about the swift-evolution mailing list