[swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases
cheyo at masters3d.com
Wed Jan 10 17:30:06 CST 2018
On Jan 10, 2018, at 8:22 AM, Paul Cantrell via swift-evolution <swift-evolution at swift.org> wrote:
>> What is your evaluation of the proposal?
> +1. Yes please. Long overdue.
>> Is the problem being addressed significant enough to warrant a change to Swift?
> It’s a long-standing sore thumb. The proposal’s evidence of community demand fits my own experience: I’ve wanted this on multiple occasions.
>> Does this proposal fit well with the feel and direction of Swift?
> Yes, and in particular, on the name bikeshedding:
> I favor property names with the “all” prefix, whether allValues or allCases. Looking over my own code, I’ve almost always used the word “all” for this when I had to hand-roll it — and either allValues or allCases make reasonable sense in my code when I substitute them.
> Whichever protocol name we choose, the property name should be consistent:
> ValueEnumerable → allValues
> CaseEnumerable → allCases
this is good point. I think it would be awesome to also have a compile time version named .cases.
.allCases would include unknown cases at runtime.
.cases would only include known at compile time cases.
> Either ValueEnumerable or CaseEnumerable would be a fine name. Contra Chris, I slightly prefer ValueEnumerable, because it extends to situations where we still want to enumerate a fixed set of possibilities which don’t strictly correspond to enum cases but still have that sort of flavor. For example, one might want:
> enum SideOfBody
> case left
> case right
> enum Limb: ValueEnumerable
> case arm(SideOfBody)
> case leg(SideOfBody)
> static let allValues =
> To my eyes, this code reads better than it would with CaseEnumerable / allCases.
>> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> Java’s enums had this from the beginning, and Josh Bloch’s design for that feature has always worked nicely. Java’s design is slightly different: `Foo.values()` returns Foo. However, Swift doesn’t need to follow either that name or type choice: (1) Java doesn’t use the term “case” as Swift does, (2) the “all” prefix better fits Swift’s API guidelines IMO, and (3) using a concrete array type has as opposed to Collection has different implications in Java than it does Swift.
> I _do_ agree that the proposal should consider constraining the Collection to be Int-indexed. Why should it ever be otherwise? What’s the motivation for leaving that open?
>> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
> Medium quick study.
> Cheers, P
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution