[swift-evolution] List of all Enum values (for simple enums)

[Zef Houssney]

Yes I agree this would be great! I think an opt-in design where you can extend existing enums to conform is awesome.

As a suggestion for the names of the methods, I think the following would be great:

enum Thing: String, Enumerable {
    case One, Two, Three
}

// available for any conforming enum:
Thing.cases // returns [Thing] = [.One, .Two, .Three]

// only available for enums with raw values:
Thing.rawValues // returns [String] = ["One", "Two", "Three"]
Regarding a name for the protocol, perhaps “Introspectable” or “Listable”?

Lastly, for enums that have cases with Associated Values, that definitely seems more complex and may be best suited for a separate discussion. I’d much rather see the “simple” version above implemented first, followed by something that deals with enums that have associated values in a later release. However, I do have a suggestion that’s different from what Brent suggested, which is that instead of returning actual enum values, I could see returning the functions associated with them as being potentially useful. I can show an example of what this might look like if anyone is interested.



> On Dec 10, 2015, at 9:37 PM, Slava Pestov via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On Dec 9, 2015, at 5:05 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Another design point to consider: instead of making *every* enum generate the “allValues” capability, it might make sense to restrict this synthesization to enums that opt into it by conforming to a protocol.  Intentionally not the right protocol name, but perhaps:
>> 
>> enum X { A, B }  // not enumerable.
>> enum X : Enumerable { A, B } // has allValues and other stuff automatically generated.
>> 
>> -Chris
>> 
> 
> The necessary information for getting enum case names (with and without payloads) is already emitted by IRGen as part of type metadata, but the runtime reflection interface for accessing it does not support this use-case (introspecting a type without a value) and in general is a bit heavy weight.
> 
> In the past we’ve talked about switching to an “opt-in” reflection model, where protocol conformance signals that metadata generation should occur. If we combine this with a nice type reflection interface, the original poster’s use-case should be taken care of well, I think.
> 
> Slava
> 
>>> 
>>> -DW
>>> 
>>>> On Dec 8, 2015, at 11:13 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>>> 
>>>>> On Dec 8, 2015, at 10:09 PM, Jacob Bandes-Storch <jtbandes at gmail.com <mailto:jtbandes at gmail.com>> wrote:
>>>>> 
>>>>> Do you have any recommendations for where in the compiler this would happen, for those of us without thorough knowledge of all parts? What would the team need to see in a proposal for it to be sufficiently complete?
>>>> 
>>>> This would slot into the same logic that synthesizes memberwise initializers on structs.  That said, I think that hashing out the right user model and set of capabilities is the first place to start.
>>>> 
>>>> -Chris
>>>> 
>>>> 
>>>>> On Tue, Dec 8, 2015 at 10:05 PM Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote:
>>>>> 
>>>>> > On Dec 8, 2015, at 9:53 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> >
>>>>> > Enums are often used without associated values:
>>>>> >
>>>>> >     enum Attribute { case Title, Date }
>>>>> >     enum Style { case Dark, Light }
>>>>> >
>>>>> > In such cases, it's very useful to be able to iterate over all possible values. But you have to do it manually:
>>>>> >
>>>>> >     extension Attribute {
>>>>> >         static var allValues: [Attribute] {
>>>>> >             return [.Title, .Date]  // imagine this x100, and not autogenerated :(
>>>>> >         }
>>>>> >     }
>>>>> >
>>>>> > It would be nice if the compiler generated this for us. It doesn't have to be an Array, but any kind of SequenceType. Maybe something like "StaticCollection". Of course, this doesn't work in the general case, but I think simple enums are common enough that it might be worth doing.
>>>>> 
>>>>> This is a commonly requested feature, and tons of people would support the ability to do this somehow.  Similarly, for integer-backed enums, many people want to be able to know the “max” enum rawValue so they can index into them.
>>>>> 
>>>>> -Chris
>>>>> 
>>>> 
>>>>  _______________________________________________
>>>> 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 <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 <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151211/09ed3d38/attachment.html>