<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div><br></div><div><br>On Jan 3, 2018, at 6:52 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">This is a very nice revision. One bikeshedding thought:<div><br></div><div>Since "unknown case" is presented as a special kind of "default", can't be mixed with "default", and can't be used in case patterns, why not "default unknown" (or "unknown default") instead of "unknown case"?</div></div></div></blockquote><div><br></div>`case _ :` is already a special case of default. <div>I’d rather have `case unknown :`</div><div>`unknown case :` is weird because of the order of `case`. </div><div><br></div><div>Another alternative is `case \unknown :`</div><div>`\unknown` would also allow pattern matching. </div><div><br></div><div><br></div><div><br></div><div><blockquote type="cite"><div><div dir="ltr"><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 3, 2018 at 8:05 PM, Jordan Rose via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><span class=""><div><blockquote type="cite"><div>On Jan 2, 2018, at 18:07, Jordan Rose <<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>> wrote:</div><br class="m_4426090214486360640Apple-interchange-newline"><div><div style="word-wrap:break-word;line-break:after-white-space"><div>[Proposal: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md" style="font-family:Helvetica,arial,sans-serif" target="_blank">https://github.com/<wbr>apple/swift-evolution/blob/<wbr>master/proposals/0192-non-<wbr>exhaustive-enums.md</a>]</div><div><br></div><div>Whew! Thanks for your feedback, everyone. On the lighter side of feedback—naming things—it seems that most people seem to like '<b>@frozen</b>', and that does in fact have the connotations we want it to have. I like it too.</div><div><br></div><div>More seriously, this discussion has convinced me that it's worth including what the proposal discusses as a <b>'future' case</b>. The key point that swayed me is that this can produce a <i>warning</i> when the switch is missing a case rather than an <i>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><br></div><div>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><br></div><div>I too would like to just do `unknown:` or `unexpected:` but that's technically a source-breaking change:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>switch foo {</div><div>case bar:</div><div> unknown:</div><div> while baz() {</div><div> while garply() {</div><div> if quux() {</div><div> break unknown</div><div> }</div><div> }</div><div> }</div><div>}</div></blockquote><div><br></div><div>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><br></div><div>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><br></div><div>---</div><div><br></div><div><div>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></div></span><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" target="_blank">https://github.com/apple/<wbr>swift-evolution/pull/777</a>.</div><div><br></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><br></div><div>Jordan</div><div><br></div><div>P.S. Enjoying the Disney references. Thanks, Nevin and Dave. :-)</div></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div></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></body></html>