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
> <[email protected]> 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 <[email protected]
> <mailto:[email protected]>> wrote:
> On Dec 30, 2017, at 3:12 PM, Jacob Bandes-Storch via swift-evolution
> <[email protected] <mailto:[email protected]>> 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
>> <[email protected] <mailto:[email protected]>> 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
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>>
>>>
>>> Jacob Bandes-Storch
>>>
>>> On Tue, Nov 14, 2017 at 9:06 PM, Brent Royal-Gordon <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>> On Nov 14, 2017, at 5:21 PM, Xiaodi Wu <[email protected]
>>>> <mailto:[email protected]>> 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
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
