On Jan 10, 2018, at 8:22 AM, Paul Cantrell via swift-evolution
<[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
