> On Feb 19, 2017, at 4:18 PM, Xiaodi Wu via swift-evolution > <swift-evolution@swift.org> wrote: > > On Sun, Feb 19, 2017 at 5:10 PM, Adrian Zubarev > <adrian.zuba...@devandartist.com <mailto:adrian.zuba...@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? -DW
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
