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

[Slava Pestov]

They would not be boxed, but there would be additional indirection required at runtime, using the same mechanism currently used for unspecialized generics.

Slava

> On Dec 19, 2017, at 6:42 PM, Kevin Ballard <kevin at sb.org> wrote:
> 
> 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 <mailto:spestov at apple.com>> wrote:
> 
>> 
>> 
>>> On Dec 19, 2017, at 3:31 PM, Kevin Ballard via swift-evolution <swift-evolution at swift.org <mailto: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/454ea4dd/attachment.html>