> On Jan 3, 2018, at 12:02 PM, Dave DeLong <sw...@davedelong.com> wrote: > > > >> On Jan 3, 2018, at 10:58 AM, Kevin Nattinger <sw...@nattinger.net >> <mailto:sw...@nattinger.net>> 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.
It sounds to me like the main thing you’re unhappy about is having to deal with unknown cases when you have a source dependency that you always build and ship with an app. I don’t think anyone is happy with that situation. Did you take a look at the sketch of a solution provided by John McCall? https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171218/042333.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171218/042333.html> > > 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 >>> 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
