<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 iPhone</div><div><br>On 3 Jan 2018, at 07:42, Goffredo Marocchi <<a href="mailto:panajev@gmail.com">panajev@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><br><div>On 3 Jan 2018, at 02:07, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div class="">[Proposal: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md" class="" style="font-family: Helvetica, arial, sans-serif;">https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md</a>]</div><div class=""><br class=""></div><div class="">Whew! Thanks for your feedback, everyone. On the lighter side of feedback—naming things—it seems that most people seem to like '<b class="">@frozen</b>', and that does in fact have the connotations we want it to have. I like it too.</div><div class=""><br class=""></div><div class="">More seriously, this discussion has convinced me that it's worth including what the proposal discusses as a <b class="">'future' case</b>. The key point that swayed me is that this can produce a <i class="">warning</i> when the switch is missing a case rather than an <i class="">error,</i> which both provides the necessary compiler feedback to update your code and allows your dependencies to continue compiling when you update to a newer SDK. I know people on both sides won't be 100% satisfied with this, but does it seem like a reasonable compromise?</div></div></blockquote><div><br></div><div>If we can optionally treat this warning as an error yeah, but considering the restricted use case, the default should still be exhaustive with unfrozen the optional keyword that can be applied to opt out of the error.</div><div><br></div><div>Regardless of that, if it is not going to cause runtime issues why should it not be a compile time error and just a warning? I think if you recompile the app and are either targeting a new SDK or updating a library you bundle that you should have to address this issue. Still, better than nothing :).</div><br><blockquote type="cite"><div><div class=""><br class=""></div><div class="">The next question is how to spell it. I'm leaning towards `unexpected case:`, which (a) is backwards-compatible, and (b) also handles "private cases", either the fake kind that you can do in C (as described in the proposal), or some real feature we might add to Swift some day. `unknown case:` isn't bad either.</div><div class=""><br class=""></div><div class="">I too would like to just do `unknown:` or `unexpected:` but that's technically a source-breaking change:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">switch foo {</div><div class="">case bar:</div><div class=""> unknown:</div><div class=""> while baz() {</div><div class=""> while garply() {</div><div class=""> if quux() {</div><div class=""> break unknown</div><div class=""> }</div><div class=""> }</div><div class=""> }</div><div class="">}</div></blockquote><div class=""><br class=""></div><div class="">Another downside of the `unexpected case:` spelling is that it doesn't work as part of a larger pattern. I don't have a good answer for that one, but perhaps it's acceptable for now.</div><div class=""><br class=""></div><div class="">I'll write up a revision of the proposal soon and make sure the core team gets my recommendation when they discuss the results of the review.</div><div class=""><br class=""></div><div class="">---</div><div class=""><br class=""></div><div class=""><div class="">I'll respond to a few of the more intricate discussions tomorrow, including the syntax of putting a new declaration inside the enum rather than outside. Thank you again, everyone, and happy new year!</div></div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></blockquote></body></html>