An alternative is a special #knownCases(of:) literal. Its value is an array literal of the enum cases known at compile time.
This could also work with enums imported from Objective-C. -- Ben > On 10 Jan 2018, at 22:54, Jordan Rose wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md > > <https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md>] > > I think this is generally reasonable, and none of the names offend me enough > to weigh in on that discussion. I do think it's a little weird that @objc > enums defined in Swift cannot conform to ValueEnumerable, just because > imported enums won't. (But especially while knee-deep in SE-0192, I think > it's correct that imported enums won't. The exception could be C enums marked > `enum_extensibility(closed)`, but I'm not convinced we need that yet.) > > The biggest problem I have is unavailable cases. An unavailable case must not > be instantiated—consider an enum where some cases are only available on iOS > and not macOS. (I bet we optimize based on this, which makes it all the more > important to get right.) > > I think you should explicitly call out that the derived implementation only > kicks in when ValueEnumerable is declared on the enum itself, not an > extension. Or if that's not the case, it should be limited to extensions in > the same module as the enum. (You could add "unless the enum is '@frozen'", > but that's not really necessary.) > > I don't think this should be implemented with a run-time function; > compile-time code generation makes more sense to me. But that's an > implementation detail; it doesn't change the language surface. > > Jordan
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
