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 <> wrote:
>> On Dec 19, 2017, at 3:31 PM, Kevin Ballard via swift-evolution 
>> <> 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
swift-evolution mailing list

Reply via email to