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