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