Simple is better. Int indexes, please. -- C. Keith Ray
* https://leanpub.com/wepntk <- buy my book? * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf * http://agilesolutionspace.blogspot.com/ > On Jan 10, 2018, at 10:44 AM, Karl Wagner via swift-evolution > <swift-evolution@swift.org> wrote: > > > >>> On 10. Jan 2018, at 17:22, 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 >> >> 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 > > > 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@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
