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 <ke...@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 <spes...@apple.com > <mailto:spes...@apple.com>> wrote: > >> >> >>> On Dec 19, 2017, at 3:31 PM, Kevin Ballard via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
