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

[Dave DeLong]

> On Jan 3, 2018, at 11:09 AM, Matthew Johnson <matthew at anandabits.com> wrote:
> 
>> 
>> On Jan 3, 2018, at 12:02 PM, Dave DeLong <swift at davedelong.com <mailto:swift at davedelong.com>> wrote:
>> 
>> 
>> 
>>> On Jan 3, 2018, at 10:58 AM, Kevin Nattinger <swift at nattinger.net <mailto:swift at nattinger.net>> wrote:
>>> 
>>>>>> [...]
>>>>>> 	2️⃣ If the enum is NOT decorated with @frozen, then I, as an app author, have to account for the possibility that the module may update from underneath my app, and I have to handle an unknown case. This is simple: the compiler should require me to add a “default:” case to my switch statement. This warning is produced IFF: the enum is coming from an external module, and the enum is not decorated with @frozen.
>>>>> 
>>>>> This does not help people who need to write a switch statement over an enum vended by a module that ships with the OS keep their code up to date as the module adds new cases. I find the example of `SKPaymentTransactionState` provided by Brent Royal-Gordon here: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170904/039512.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170904/039512.html> to be compelling.  There are rare but legitimate reasons to switch over all known cases of a non- at frozen enum that ship with the OS.  These use cases deserve proper language support.  I think Jordan’s solution strikes a good balance.
>>>> 
>>>> I disagree that more is needed. In the case of the transaction state, it should not be marked as @moana, and so the compiler would force you to add a “default” case to your switch statements. The switch statements would still be exhaustive with all known cases (if you choose to handle all known cases), but you’d still need a default case because there might be new transaction states in the future.
>>> 
>>> And then you don't get the compiler error/warning when you start compiling against the next OS update that changes the enum. That is an absolutely unacceptable loss of compile-time checks.
>> 
>> Ah, that’s an excellent point! Thanks for pointing that out.
>> 
>> In that case, I revise my proposal:
>> 
>> 1️⃣ a @frozen/@tangled/@moana attribute for enums that’s only consulted on externally-linked modules
>> 2️⃣ a “future case:” statement that’s only required on externally-linked, non- at moana enums. That way, if the enum adds a new case in the future, you’ll still get a switch warning about handling all the cases. And then if you want, you could “fallthrough” from this to a “default” case, or vice-versa, or have separate implementations.
> 
> It sounds to me like the main thing you’re unhappy about is having to deal with unknown cases when you have a source dependency that you always build and ship with an app.  I don’t think anyone is happy with that situation.  

That’s definitely part of it. The other main part is that I’m hugely resistant to adding extraneous syntax when a solution that’s simpler for users exists.

> Did you take a look at the sketch of a solution provided by John McCall?  https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171218/042333.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171218/042333.html>
I’ve read that email several times and don’t understand how it relates.

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20180103/c0722c9c/attachment.html>