[swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

Kevin Ballard kevin at sb.org
Tue Dec 19 20:42:37 CST 2017

Isn’t this going to turn both structs and non-C-like enums into types that need to be auto-boxed (as the client won’t be able to rely on knowing the fixed size anymore)? This seems like a performance hazard.

-Kevin Ballard

> On Dec 19, 2017, at 5:35 PM, Slava Pestov <spestov at apple.com> wrote:
>> On Dec 19, 2017, at 3:31 PM, Kevin Ballard via swift-evolution <swift-evolution at swift.org> wrote:
>> So I guess I’m saying, I want more thought put on the topic of whether enums defined in Swift should actually default to non-exhaustive, and I’m now leaning towards the idea that they should remain exhaustive (but Obj-C enums will still default to non-exhaustive).
> This would introduce an inconsistency between enums and structs. Structs will not be fixed-contents by default (there’s a proposal coming for that), which means you will be able to add stored properties after the fact. For this reason it makes more sense to me to also make enums non-exhaustive by default so that new cases can be added.
> Slava
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171219/b581f132/attachment.html>

More information about the swift-evolution mailing list