[swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

Jordan Rose jordan_rose at apple.com
Wed Jan 10 16:54:47 CST 2018


[Proposal: 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20180110/dd25910b/attachment.html>


More information about the swift-evolution mailing list