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

David Waite david at alkaline-solutions.com
Sun Feb 19 21:36:53 CST 2017

> On Feb 19, 2017, at 4:18 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
> On Sun, Feb 19, 2017 at 5:10 PM, Adrian Zubarev <adrian.zubarev at devandartist.com <mailto:adrian.zubarev at devandartist.com>> wrote:
> Because someInstance["key", .string("key1"), .integer(1), .string(stringKeyInstance), .integer(intIndexInstance), .integer(intIndexInstance), …] is simply ugly and should be hidden. Such API looks horrible.
> I agree. This cries out for improvements to enums. 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`.

Agreed, if the use case is meant for working around the lack of union types, we should be very careful in deciding whether the fix should be:
1. Making enums syntactically better for representing union types
2. Adding union types to the language proper, distinct from enums
3. Using a type (such as a closed protocol) to ‘tag’ members of a union type
4. Propose the SubscriptParameter pattern given before as ‘the’ way to solve this problem.

Are closed protocols a quick fix or the pattern going forward?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170219/612afe05/attachment.html>

More information about the swift-evolution mailing list