This looks really nice. Thank you for doing the legwork of researching previous discussions and writing up a detailed proposal!
The motivation discusses the common use case of using an enum in a data source implementation which requires 0-based Int indices. However, the proposed solution as-written does not specifically address this use case. Is the intent that the compiler-synthesized implementation always uses indices meeting 0-based Int requirement? If so it is probably worth stating this explicitly in the proposal. Sent from my iPad > On Dec 30, 2017, at 5:12 PM, Jacob Bandes-Storch via swift-evolution > <swift-evolution@swift.org> wrote: > > Sorry for the delay. I've just updated the proposal text to incorporate > various changes, some contributed by others. > > https://github.com/jtbandes/swift-evolution/blob/case-enumerable/proposals/0000-derived-collection-of-enum-cases.md > > Robert's implementation is a good start, but will need to be updated to match > the naming choice in the final proposal, and to use associatedtype. > >> On Fri, Dec 8, 2017 at 9:19 PM, Step Christopher >> <schristop...@bignerdranch.com> wrote: >> Has this stalled out again? I would like to help with the proposal and even >> attempt implementation. >> >> I also need to catch up on the resilient discussion regarding enum case >> ordering. >> >>> On Nov 14, 2017, at 10:50 PM, Jacob Bandes-Storch via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> >>> >>> Jacob Bandes-Storch >>> >>> On Tue, Nov 14, 2017 at 9:06 PM, Brent Royal-Gordon >>> <br...@architechies.com> wrote: >>>>>> On Nov 14, 2017, at 5:21 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: >>>>>> >>>>>> 1. It must be possible to easily access the count of values, and to >>>>>> access any particular value using contiguous `Int` indices. This could >>>>>> be achieved either by directly accessing elements in the list of values >>>>>> through an Int subscript, or by constructing an Array from the list of >>>>>> values. >>>>>> >>>>>> 2. It must be possible to control the order of values in the list of >>>>>> values, either by using source order or through some other simple, >>>>>> straightforward mechanism. >>>>> >>>>> OK, first of all, nowhere in the proposal text are these requirements >>>>> stated as part of the use case. You're free to put forward new use cases, >>>>> but here I am trying to design the most elegant way to fulfill a stated >>>>> need and you're telling me that it's something other than what's written. >>>> >>>> Honestly, re-reading the proposal, it never cites a fully-formed use case. >>>> Instead, it cites several blog posts, Stack Overflow questions, and small >>>> code samples without digging in to the underlying reasons why developers >>>> are doing what they're doing. Most of the people discussing it so far seem >>>> to have had a tacit understanding that we wanted roughly Array-like >>>> access, but we haven't explicitly dug into which properties of an Array >>>> are important. >>>> >>>> (If anyone involved feels like they had a different understanding of the >>>> use case, please speak up.) >>>> >>>> I think this is a place where the proposal can be improved, and I'm >>>> willing to do some writing to improve it. >>> >>> For the record, I would be happy to add co-authors (or even relinquish >>> authorship entirely—I don't really care whose name is on this, it just >>> needs to happen!) if you or anyone else has improved wording, motivation, >>> justification, etc. to contribute. >>> _______________________________________________ >>> 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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
