> On Jan 3, 2018, at 11:47 AM, BJ Homer <bjho...@gmail.com> wrote: > > > >> On Jan 3, 2018, at 10:36 AM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto: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.
There is definitely not a good answer here. Making the library responsible to only send known values is not a solution. This type represents the state of an entity and it should do so as accurately as possible. Sometimes a new state cannot be mapped to one of the previous states. How would you have StoreKit handle the deferred state for old clients? My position is that the situation is much worse for an app developer when they don’t even get the assistance of a compiler warning when updating to the new SDK. App developers are sometimes forced to deal with unfortunate cases like this. Any help the language can provide is appreciated. > > -BJ
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
