In addition to what Chris said: enums imported from C and @objc enums can both have extensions and conform to protocols, so IMO it should be legal to write something like `extension Foundation.ComparisonResult: ValueEnumerable {}`.
Félix > Le 30 déc. 2017 à 19:00, Jacob Bandes-Storch via swift-evolution > <swift-evolution@swift.org> a écrit : > > Re-reading this thread and thinking about it more, I think I agree :) > Updating again... > > On Sat, Dec 30, 2017 at 3:44 PM, Chris Lattner <clatt...@nondot.org > <mailto:clatt...@nondot.org>> wrote: > On Dec 30, 2017, at 3:12 PM, Jacob Bandes-Storch via swift-evolution > <swift-evolution@swift.org <mailto: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> > I would really love to see this happen. I did a pass over the proposal, I > strong suggest that you get Joe Groff’s input on this, because he has some > opinions as well. > > IMO, the proposal looks really great except for one thing: In "proposed > solution”, I think it is very important that conformance to ValueEnumerable > be explicitly requested in the code. Specifically: > > enum Ma { case 马, 吗, 妈, 码, 骂, 麻, 🐎, 🐴 } > Ma.allValues // error. > > enum Ma : ValueEnumerable { case 马, 吗, 妈, 码, 骂, 麻, 🐎, 🐴 } > Ma.allValues // works! > > > This is for two reasons: > 1) Consistency with other similar features in Swift. Types are not hashable > just because their members could be. This is because we want people to think > about and explicitly opt into API features like this. > 2) To align with our resilience design. An enum with no value-associated > cases today could acquire them in the future, and doing so would implicitly > remove this conformance. This would be surprising and bad. > > Thanks for pushing this forward! > > -Chris > > > > > > >> 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. >> >> 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 <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