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

[BJ Homer]

> On Jan 3, 2018, at 10:36 AM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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 agree that the SKPaymentTransactionState example is compelling. However, I don’t understand what actual code a developer would put in the “unexpected case:” clause. That enum is related to handling in-app purchases; it’s expected that the app would react in some way to a transaction changing state. What should the app do if the transaction enters an “unexpected” state? Pop up an error to the user that the user can do nothing about? It’s great to get a compiler warning about a case like when the developer builds with the new SDK, but I don’t understand what the already-shipped app is supposed to do in a case like this.

For the SKPaymentTransactionState case, at least, it seems like the library needs to be responsible to only send known values to the client. Otherwise, the app can have no idea what to do.

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