On Sun, Feb 19, 2017 at 5:55 PM, Adrian Zubarev < adrian.zuba...@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...@gmail.com) schrieb: > > On Sun, Feb 19, 2017 at 5:26 PM, Adrian Zubarev < > adrian.zuba...@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. > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution