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

[Matthew Johnson]

> 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 <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.  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>
> 
> Dave
> 
>> 
>>> 
>>> In those cases, your app could decide what to do, if that’s possible at all. Maybe there’s other transaction information you could introspect to determine if it succeeded or is still pending or whatever, and then your app could respond as you see fit.
>>> 
>>> Dave
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 

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