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


> On Dec 19, 2017, at 6:42 PM, Kevin Ballard <> 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 < 
> <>> 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