[swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

[Cheyo Jimenez]

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 =
>         [
>         arm(.left),
>         arm(.right),
>         leg(.left),
>         leg(.right)
>         ]
>       }
> 
> 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
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20180110/84d96e79/attachment.html>