<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 3, 2018, at 11:47 AM, BJ Homer <<a href="mailto:bjhomer@gmail.com" class="">bjhomer@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jan 3, 2018, at 10:36 AM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><br class=""></div><div class="">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: <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170904/039512.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170904/039512.html</a> 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.</div></div></div></blockquote></div><br class=""><div class="">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.</div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">For the SKPaymentTransactionState case, at least, it seems like the <i class="">library</i> needs to be responsible to only send known values to the client. Otherwise, the app can have no idea what to do.</div></div></div></blockquote><div><br class=""></div><div>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?</div><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">-BJ</div></div></div></blockquote></div><br class=""></body></html>