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

[Matthew Johnson]

Sent from my iPad

> On Jan 3, 2018, at 12:20 PM, Dave DeLong <swift at davedelong.com> wrote:
> 
> 
> 
>>> 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> wrote:
>>>> 
>>>> 
>>>> 
>>>> On Jan 3, 2018, at 10:58 AM, Kevin Nattinger <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 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.

That’s fair.  If we didn’t have a compelling motivating example I would be more reluctant about the need to add syntax here, but we do have such an example.

> 
>> 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
> 
> I’ve read that email several times and don’t understand how it relates.

I should have also linked to his previous email.  Does this one help clarify what he has in mind?  https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171218/042329.html

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