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

Gwendal Roué gwendal.roue at gmail.com
Fri Jan 5 04:30:06 CST 2018


> Le 5 janv. 2018 à 10:33, Goffredo Marocchi <panajev at gmail.com> a écrit :
> 
> Fair concerns Gwendal, but why can’t the default in these cases be just exhaustive / frozen unless the library developer explicitly marks it as “unfrozen/non exhaustive” and the compiler can warn the users when they switch over it instead of throwing an error by default (the user can still treat warnings as errors if they want and suppress this warning if they wanted to in this vision)?

The proposal suggests default non-frozen enums. If I remember well, that's because it's easier to switch from non-frozen to frozen than the opposite.

I buy this ABI-based argument very well, since 1. I'm not an ABI expert, and 2. as a library author I will scratch my head for each of my public enums anyway.

Now I still think that the choice is really uneasy. I've given some GRDB examples. And I'd also like to know how ABI experts would have introduced and evolved SKPaymentTransactionState in a hypothetic Swift 5+ world.

Gwendal



More information about the swift-evolution mailing list