> On Jan 3, 2018, at 10:36 AM, Matthew Johnson via swift-evolution
> <swift-evolution@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-@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
