> On 7. Jan 2018, at 18:47, Robert Widmann <devteam.cod...@gmail.com> wrote: > > > > ~Robert Widmann > > 2017/12/31 11:02、Karl Wagner via swift-evolution <swift-evolution@swift.org > <mailto:swift-evolution@swift.org>>のメール: > >> >> >>> On 31. Dec 2017, at 00:12, 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> >>> >>> 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]”? > > The exact meaning of a synthesized conformance to ValueEnumerable is > > - The type is an enum > - That enum is not @objc > - That enum is composed entirely of cases that have no associated values > - That enum is defined in the module declaring the synthesized conformance > (ie no extensions - same as Equatable and Hashable) > > The exact meaning of a general conformance is > > - The type has a finite number of possible values inhabiting it > > As you note, integral types and Bool and some enums that fall outside the > scope of the synthesis requirements fit this mold quite nicely. We do not > include them in the proposal partially to keep things simple, partially > because we’d be stepping on Range’s toes, and partially because synthesis for > structs is tricky in the general case. If deemed particularly useful in the > future, these conformance can be added. > >> >> 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()”? > > The interface for the protocol makes no ordering guarantees, but the > synthesized conformance uses source-order because that’s currently the way > the runtime metadata (which will become ABI) is implemented. It is up to > authors to document the ordering stability of the value collection or to let > the compiler handle it for them. > > ~Robert Widmann >
Cool. I definitely think it’s worth having this protocol in the standard library. - Karl >> >> - 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 <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
