[swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

[Karl Wagner]

> On 31. Dec 2017, at 00:12, Jacob Bandes-Storch via swift-evolution <swift-evolution at 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 <schristopher at bignerdranch.com <mailto:schristopher at 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 at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> 
>> 
>> Jacob Bandes-Storch
>> 
>> On Tue, Nov 14, 2017 at 9:06 PM, Brent Royal-Gordon <brent at architechies.com <mailto:brent at architechies.com>> wrote:
>>> On Nov 14, 2017, at 5:21 PM, Xiaodi Wu <xiaodi.wu at gmail.com <mailto:xiaodi.wu at 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 at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171231/c78a4dd9/attachment.html>