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@swift.org> wrote: > On Apr 22, 2016, at 11:48 PM, Jacob Bandes-Storch <jtban...@gmail.com > <javascript:_e(%7B%7D,'cvml','jtban...@gmail.com');>> wrote: > On Fri, Apr 22, 2016 at 11:34 PM, John McCall <rjmcc...@apple.com > <javascript:_e(%7B%7D,'cvml','rjmcc...@apple.com');>> wrote: > >> On Apr 22, 2016, at 11:11 PM, Jacob Bandes-Storch <jtban...@gmail.com >> <javascript:_e(%7B%7D,'cvml','jtban...@gmail.com');>> wrote: >> On Fri, Apr 22, 2016 at 10:50 PM, John McCall <rjmcc...@apple.com >> <javascript:_e(%7B%7D,'cvml','rjmcc...@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.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution