[swift-evolution] ValueEnumerable protocol with derived implementation for enums

[Howard Lovatt]

If you wrote:

    enum Ex { case one, two, three }

And the compiler translated that into the equivalent of:


   - struct Ex : OptionSetType
   <http://swiftdoc.org/v2.2/protocol/OptionSetType> {
   -   let rawValue: UInt <http://swiftdoc.org/v2.2/type/Int>
   -   init(rawValue: UInt <http://swiftdoc.org/v2.2/type/Int>) { self
   .rawValue = rawValue }
   -
   -   static let one = Ex(rawValue: 1)
   -   static let two = Ex(rawValue: 2)
   -   static let three = Ex(rawValue: 4)
   -   static let values: Ex = [one, two, three]
   - }


This would allow set behaviour which I found very handy in Java and be as
robust as any other option set.

PS Int only applicable for < 64 cases. Need BigInt for others.

On Sunday, 24 April 2016, John McCall via swift-evolution <
swift-evolution at swift.org> wrote:

> On Apr 22, 2016, at 11:48 PM, Jacob Bandes-Storch <jtbandes at gmail.com
> <javascript:_e(%7B%7D,'cvml','jtbandes at gmail.com');>> wrote:
> On Fri, Apr 22, 2016 at 11:34 PM, John McCall <rjmccall at apple.com
> <javascript:_e(%7B%7D,'cvml','rjmccall at apple.com');>> wrote:
>
>> On Apr 22, 2016, at 11:11 PM, Jacob Bandes-Storch <jtbandes at gmail.com
>> <javascript:_e(%7B%7D,'cvml','jtbandes at gmail.com');>> wrote:
>> On Fri, Apr 22, 2016 at 10:50 PM, John McCall <rjmccall at apple.com
>> <javascript:_e(%7B%7D,'cvml','rjmccall at apple.com');>> wrote:
>>
>>>
>>> I have not been following this discussion, but I would be extremely
>>> antsy about guaranteeing any particular representation for the set of
>>> values.  Guaranteeing a contiguous array implementation seems like a really
>>> bad idea, especially if that's taken to mean that we're going to actually
>>> provide a static global array.  But there's no way to avoid providing a
>>> public API, because a public conformance itself implies a public API with
>>> some level of corresponding overhead.
>>>
>>
>> A "compiler magic" version of the feature, like #allValues(MyEnum), could
>> generate a static array *internal* to the caller's module, but I'm sure
>> there are implications or details of this which I'm not aware of.
>>
>>
>> That cannot be reconciled with resilience.  The caller cannot reliably
>> know the set of stored cases; only the defining module can.
>>
>> For similar reasons, only the defining module can be allowed to magically
>> derive a conformance to your protocol, if indeed it's done with a protocol.
>>
>
> What should/can this mean for enums imported from Obj-C, via other
> modules, or bridging headers / custom module maps? In these cases, the
> defining module has no Swift code. Is there a way to do it with
> pre-existing metadata in the module?
>
>
> Imported declarations are always something of a special case for this sort
> of thing.
>
> It is possible to import an enum as "open", meaning that the library
> reserves the right to add new enumerators; it would never be possible to
> make such a type ValuesEnumerable, at least via the built-in magic.  But
> otherwise we could certainly give imported enums this conformance by
> default if we wanted to.
>
> John.
>


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