Sent from my iPad
> On Jan 3, 2018, at 12:20 PM, Dave DeLong <sw...@davedelong.com> wrote: > > > >>> On Jan 3, 2018, at 11:09 AM, Matthew Johnson <matt...@anandabits.com> wrote: >>> >>> >>>> 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> 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 >>>>>> 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. > > That’s definitely part of it. The other main part is that I’m hugely > resistant to adding extraneous syntax when a solution that’s simpler for > users exists. That’s fair. If we didn’t have a compelling motivating example I would be more reluctant about the need to add syntax here, but we do have such an example. > >> 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 > > I’ve read that email several times and don’t understand how it relates. I should have also linked to his previous email. Does this one help clarify what he has in mind? https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171218/042329.html > > Dave
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
