I don’t see it, can you elaborate a whole proposal first, otherwise I’m not
convinced. Why?
--
Adrian Zubarev
Sent with Airmail
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
