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

[Jacob Bandes-Storch]

On Wed, Dec 9, 2015 at 5:26 PM, Chris Lattner <clattner at apple.com> wrote:

>
> On Dec 9, 2015, at 5:24 PM, Jacob Bandes-Storch <jtbandes at gmail.com>
> wrote:
>
> On Wed, Dec 9, 2015 at 5:05 PM, Chris Lattner <clattner at apple.com> wrote:
>
>>
>> On Dec 9, 2015, at 10:19 AM, David Waite <david at alkaline-solutions.com>
>> wrote:
>>
>> There are a number of possible proposals for enhancements I see off the
>> bat for “basic" enums (without associated data):
>>
>> 1. A generated implementation of SequenceType based on declaration order
>> 2. A second interface or extension to the enum type could supply static
>> max and min properties when the RawValue is Comparable
>> 3. For enums with a String raw value, CustomStringConvertible and
>> Streamable might make sense as well. You would likely want
>> CustomDebugStringConvertible to also be defined to supply the original
>> type-based value.
>>
>>
>> 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
>>
>
> And I suppose it would have to be possible to add this conformance to a
> pre-existing type?  You'd want to be able to do "extension NSTextAlignment
> : Enumerable {}”.
>
>
> Yes, exactly.  This would allow it to work with C types as you suggest, as
> well as providing the ability to retroactively provide it for Swift enums
> that didn’t anticipate the need.
>
> But I'm not sure if it would work well to generate this on-demand; might
> work better to do it at interface-generation time, along with OptionSetType
> conformances, etc.
>
>
> I’m not sure what you mean here,
>
> -Chris
>

I'd have to look at the code before I'll be able to ask a fully coherent
question (you mentioned the same place memberwise initializers are
synthesized).

I was guessing that having multiple "extension NSSortOptions : Enumerable
{}" in different modules (or different files in the same module) might
cause problems, so you'd have to do it only one place — i.e. NSSortOptions
would either be imported as protocol<OptionSetType, Enumerable> or it
wouldn't, with no way to change it post-hoc from user code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151209/2f7ec301/attachment.html>