> On 31. Dec 2017, at 00:12, 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 > > <https://github.com/jtbandes/swift-evolution/blob/case-enumerable/proposals/0000-derived-collection-of-enum-cases.md> > > Robert's implementation > <https://github.com/apple/swift-evolution/pull/114#issuecomment-337105126> is > a good start, but will need to be updated to match the naming choice in the > final proposal, and to use associatedtype.
Looks good, but I have two questions: 1) What is the exact semantic meaning of ValueEnumerable? Does it somehow imply an enum? Or is it simply an abstraction for any type with a “fixed, finite set of [values]”? I ask because the standard library includes some non-enum types which also fit that definition: namely Bool, Unicode characters, and the various integer types. Would it make sense for those types to also conform (regardless if its part of the proposal; I’m asking if you would consider that a “misuse” of the protocol)?. 2) Is the order of values in the Collection generally meaningful, or not? If not, would it be reasonable for types which conform to Comparable to always return a sorted Collection? Or should we manually sort it with “MyEnum.allValues.sorted()”? - Karl > > On Fri, Dec 8, 2017 at 9:19 PM, Step Christopher > <schristop...@bignerdranch.com <mailto: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 <mailto:swift-evolution@swift.org>> wrote: > >> >> >> Jacob Bandes-Storch >> >> On Tue, Nov 14, 2017 at 9:06 PM, Brent Royal-Gordon <br...@architechies.com >> <mailto:br...@architechies.com>> wrote: >>> On Nov 14, 2017, at 5:21 PM, Xiaodi Wu <xiaodi...@gmail.com >>> <mailto: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 <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
