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