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

[Dave DeLong]

Yes please to Int indexes.

One of the things I despise most about the Collection protocol is how it allows for arbitrary index types. That, IMO, was an awful, awful mistake.

Dave

> On Jan 10, 2018, at 11:45 AM, C. Keith Ray via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Simple is better. Int indexes, please. 
> 
> --
> C. Keith Ray
> 
> * https://leanpub.com/wepntk <https://leanpub.com/wepntk> <- buy my book?
> * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf <http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf>
> * http://agilesolutionspace.blogspot.com/ <http://agilesolutionspace.blogspot.com/>
> 
> On Jan 10, 2018, at 10:44 AM, Karl Wagner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> 
>> 
>>> On 10. Jan 2018, at 17:22, Paul Cantrell via swift-evolution <swift-evolution at swift.org <mailto: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
>>> 
>>> 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 <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> 
>> I don’t agree that the Collection should be Int-indexed. Source-order is not a very strong guarantee IMO, and it wouldn’t be good if people started writing things like "MyEnum.allValues[3]” to reference a specific case.
>> 
>> If you know the specific case you are looking for, just write it directly. If you found an interesting case while iterating allValues, remember its (opaque) index and come back to it later.
>> 
>> I’m not a fan of Int-indexes in general. It’s practical to allow it for Array, but in general, for generic Collections, I think it implies an awful lot of knowledge about the Collection’s contents.
>> 
>> - Karl
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> 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/c8aa3fd5/attachment.html>