> On Jan 3, 2018, at 10:58 AM, Kevin Nattinger <[email protected]> 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-@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-@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. 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 >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
