<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><br><br><div id="AppleMailSignature">Sent from my iPad</div><div><br>On Jan 3, 2018, at 12:20 PM, Dave DeLong <<a href="mailto:swift@davedelong.com">swift@davedelong.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 3, 2018, at 11:09 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><div class=""><br class="Apple-interchange-newline">On Jan 3, 2018, at 12:02 PM, Dave DeLong <<a href="mailto:swift@davedelong.com" class="">swift@davedelong.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jan 3, 2018, at 10:58 AM, Kevin Nattinger <<a href="mailto:swift@nattinger.net" class="">swift@nattinger.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class=""><blockquote type="cite" class=""><div class=""><div class="" 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;"><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space;"><div class=""><font class="">[...]</font></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>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.</div></div></div></blockquote><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></div></blockquote><div class=""><br class=""></div><div class="">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.</div></div></div></blockquote><div class=""><br class=""></div><div class="">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.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Ah, that’s an excellent point! Thanks for pointing that out.</div><div class=""><br class=""></div><div class="">In that case, I revise my proposal:</div><div class=""><br class=""></div><div class="">1️⃣ a @frozen/@tangled/@moana attribute for enums that’s only consulted on externally-linked modules<br class="">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.</div></div></div></div></blockquote><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=""><br class=""></div><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="">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. </div></div></blockquote><div><br class=""></div><div>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.</div></div></div></blockquote><div><br></div>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.<div><br><blockquote type="cite"><div><div><br class=""><blockquote type="cite" class=""><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="">Did you take a look at the sketch of a solution provided by John McCall? <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171218/042333.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171218/042333.html</a></div></div></blockquote><div><br class=""></div><div>I’ve read that email several times and don’t understand how it relates.</div></div></div></blockquote><div><br></div><div>I should have also linked to his previous email. Does this one help clarify what he has in mind? <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171218/042329.html">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171218/042329.html</a></div><br><blockquote type="cite"><div><div><div><br class=""></div><div>Dave</div></div></div></blockquote></div></body></html>