<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Jan 2, 2018, at 18:07, Jordan Rose &lt;<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">[Proposal:&nbsp;<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>&nbsp;when the switch is missing a case rather than an <i class="">error,</i>&nbsp;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&nbsp;sides won't be 100% satisfied with this, but does it seem like a reasonable compromise?</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="">&nbsp; unknown:</div><div class="">&nbsp; while baz() {</div><div class="">&nbsp; &nbsp; while garply() {</div><div class="">&nbsp; &nbsp; &nbsp; if quux() {</div><div class="">&nbsp; &nbsp; &nbsp; &nbsp; break unknown</div><div class="">&nbsp; &nbsp; &nbsp; }</div><div class="">&nbsp; &nbsp; }</div><div class="">&nbsp; }</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></div></blockquote><br class=""></div><div>I ended up doing these in the opposite order, writing up the new proposal first and not yet responding to the discussion that's further out. You can read my revisions at <a href="https://github.com/apple/swift-evolution/pull/777" class="">https://github.com/apple/swift-evolution/pull/777</a>.</div><div><br class=""></div><div>In particular, I want to at least address:</div><div>- Dave D and Drew C's points about versioned libraries / linking semantics of modules.</div><div>- Jason M's point about migration</div>and I'll do one more pass over the thread to see if there's anything else I didn't address directly. (That doesn't mean everyone who disagrees, just messages where I think there's more I can do to explain why the proposal is the way it is.)<div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><div class="">P.S. Enjoying the Disney references. Thanks, Nevin and Dave. :-)</div></body></html>