>>> [...] >>> 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. > > 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 > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
