<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=""><blockquote type="cite" class="">On 3 Jan 2018, at 02:07, Jordan Rose wrote:<br class=""></blockquote><div><blockquote type="cite" class=""><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: <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></div></blockquote><div><br class=""></div><div><div>Should there be a new Clang attribute for "frozen" enums? Then the existing `__attribute__((enum_extensibility(closed)))` would only prevent "private" cases (and not future "public" cases).</div><div><br class=""></div><div><<a href="https://clang.llvm.org/docs/AttributeReference.html#enum-extensibility-clang-enum-extensibility" class="">https://clang.llvm.org/docs/AttributeReference.html#enum-extensibility-clang-enum-extensibility</a>></div></div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><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 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></blockquote><div><br class=""></div><div><div>You might end up with `case .unknown:` and `unknown case:` in the same switch.</div><div><br class=""></div><div>e.g. <<a href="https://developer.apple.com/documentation/photos/phassetmediatype" class="">https://developer.apple.com/documentation/photos/phassetmediatype</a>></div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>```</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>switch mediaType {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>case .image, .video, .audio:</div><div><span class="Apple-tab-span" style="white-space:pre"> </span> break</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>case .unknown:</div><div><span class="Apple-tab-span" style="white-space:pre"> </span> break</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>unknown case:</div><div><span class="Apple-tab-span" style="white-space:pre"> </span> break</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>```</div><div><br class=""></div><div>-- Ben</div><div class=""><br class=""></div></div></div></body></html>