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

[Jacob Bandes-Storch]

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
<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 <
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> wrote:
>
>
>
> Jacob Bandes-Storch
>
> On Tue, Nov 14, 2017 at 9:06 PM, Brent Royal-Gordon <
> brent at architechies.com> wrote:
>
>> On Nov 14, 2017, at 5:21 PM, Xiaodi Wu <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
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171230/29e2b673/attachment.html>