<div><br><div class="gmail_quote"><div dir="auto">On Thu, Jan 4, 2018 at 17:15 Cheyo J. Jimenez &lt;<a href="mailto:cheyo@masters3d.com">cheyo@masters3d.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On Jan 4, 2018, at 11:53 AM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:</div><br class="m_-6520709161405088222Apple-interchange-newline"><div><div dir="auto" style="font-family:Helvetica;font-size:13px;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"><br class="m_-6520709161405088222Apple-interchange-newline">On Thu, Jan 4, 2018 at 13:46 Cheyo Jimenez &lt;<a href="mailto:cheyo@masters3d.com" target="_blank">cheyo@masters3d.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="font-family:Helvetica;font-size:13px;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;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div></div><div><br></div><div><br>On Jan 4, 2018, at 10:49 AM, Jordan Rose &lt;<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>&gt; wrote:<br><br></div><blockquote type="cite"><div>I&#39;ll admit I hadn&#39;t thought of using &quot;unknown default&quot; (or &quot;default unknown&quot;). I don&#39;t think that&#39;s terrible, but I mildly prefer `unknown case` because it builds on the &quot;pun&quot; that enum elements are also defined using &#39;case&#39;. If anything hits this part of the switch, it really will be an &quot;unknown case&quot;, i.e. a statically-unknown enum element.<div><br></div><div>To Cheyo&#39;s point, if this<span class="m_-6520709161405088222Apple-converted-space"> </span><i>were</i> to be a single token I&#39;d probably spell it #unknown, like #available. Then we&#39;d have `case #unknown:` and something that naturally expands to other pattern positions. I found that less aesthetically pleasing, though, and so a context-sensitive keyword seemed like the way to go.</div><div><br></div><div>(For the record, though, I wouldn&#39;t describe `case _` as a special case of `default`. They do exactly the same thing, and `_` is a useful pattern in other contexts, so if anything the current `default` should be thought of as syntactic sugar for `case _`.)</div></div></blockquote><div><br></div></div><div dir="auto"><div>Can case _ be mixed with unknown case? How can we match all compile time known cases but exclude future cases?</div></div></blockquote><div dir="auto" style="font-family:Helvetica;font-size:13px;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"><br></div><div dir="auto" style="font-family:Helvetica;font-size:13px;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">What’s your use case for that? That eliminates the possibility of “unknown case” giving you compile-time warnings for subsequently added cases, which was the entire purpose of adding the syntax in the first place.</div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>I was thinking of a generalized `unknown case` pattern but that is <a href="https://github.com/apple/swift-evolution/pull/777/files#diff-a68dc745ee86d09566b232b6954c5158R321" target="_blank">out of scope for this proposal.</a> </div><div><div><br></div><div><div>switch excuse {</div><div> case .eatenByPet :</div><div>   //…</div><div> unknown case:</div><div>   // …</div><div> case _:</div><div>   // …</div><div> }</div></div></div><br><blockquote type="cite"><div><div dir="auto" style="font-family:Helvetica;font-size:13px;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"><br></div><blockquote class="gmail_quote" style="font-family:Helvetica;font-size:13px;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;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div>Should there be something like `case *` that would capture all currently known cases during compile time? case * and case _ would be the same in exhaustive enums. </div></div></blockquote></div></blockquote><div><br></div><div>This is why I was suggesting another pattern that only captures known cases at compile time:</div><div><br></div><div><div>switch excuse {</div><div> case .eatenByPet :</div><div>   //…</div><div><div> case * : //  All cases captured at compile time. </div><div>   // …</div></div><div> unknown case:</div><div>   // …</div><div> }</div></div></div></div><div style="word-wrap:break-word"><div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">Sorry, I don’t understand. However you spell it, what is your use case for this? The stated purpose of “unknown case” is to gain compile-time exhaustiveness testing, but this would not allow for that.</div><div dir="auto"><br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><blockquote class="gmail_quote" style="font-family:Helvetica;font-size:13px;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;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><br></div><div><br></div><blockquote type="cite"><div><div><br></div><div>I&#39;ll add these points to the &quot;Alternatives Considered&quot; section in the PR later today.</div><div><br></div><div>Jordan<br><div><br><div><div><br><blockquote type="cite"><div>On Jan 3, 2018, at 22:56, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:</div><br class="m_-6520709161405088222m_-3214780750878788621Apple-interchange-newline"><div>As has already been said, “case unknown” is source-breaking because it conflicts with any real cases named “unknown”; “\unknown” looks like a key path but isn’t, and I wonder if it would potentially conflict with existing key paths.<br><br>In any case, my point was not to bikeshed the “unknown” part, but to ask whether any consideration had been made to have the feature presented as a flavor of default instead of a flavor of case.<br><br><div class="gmail_quote"><div>On Wed, Jan 3, 2018 at 23:57 Cheyo Jimenez &lt;<a href="mailto:cheyo@masters3d.com" target="_blank">cheyo@masters3d.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div></div><div><br></div><div><br>On Jan 3, 2018, at 6:52 PM, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><div>This is a very nice revision. One bikeshedding thought:<div><br></div><div>Since &quot;unknown case&quot; is presented as a special kind of &quot;default&quot;, can&#39;t be mixed with &quot;default&quot;, and can&#39;t be used in case patterns, why not &quot;default unknown&quot; (or &quot;unknown default&quot;) instead of &quot;unknown case&quot;?</div></div></div></blockquote><div><br></div></div><div dir="auto">`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><div dir="auto"><div><br></div><div><br></div><div><br></div><div><blockquote type="cite"><div><div><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 class="m_-6520709161405088222Apple-converted-space"> </span><span>&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span><span class="m_-6520709161405088222Apple-converted-space"> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><span><div><blockquote type="cite"><div>On Jan 2, 2018, at 18:07, Jordan Rose &lt;<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>&gt; wrote:</div><br class="m_-6520709161405088222m_-3214780750878788621m_3038813019960738014m_4426090214486360640Apple-interchange-newline"><div><div style="word-wrap:break-word"><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/apple/swift-evolution/blob/master/proposals/0192-non-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 &#39;<b>@frozen</b>&#39;, 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&#39;s worth including what the proposal discusses as a<span class="m_-6520709161405088222Apple-converted-space"> </span><b>&#39;future&#39; case</b>. The key point that swayed me is that this can produce a<span class="m_-6520709161405088222Apple-converted-space"> </span><i>warning</i> when the switch is missing a case rather than an<span class="m_-6520709161405088222Apple-converted-space"> </span><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&#39;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&#39;m leaning towards `unexpected case:`, which (a) is backwards-compatible, and (b) also handles &quot;private cases&quot;, 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&#39;t bad either.</div><div><br></div><div>I too would like to just do `unknown:` or `unexpected:` but that&#39;s technically a source-breaking change:</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>switch foo {</div><div>case bar:</div><div> <span class="m_-6520709161405088222Apple-converted-space"> </span>unknown:</div><div> <span class="m_-6520709161405088222Apple-converted-space"> </span>while baz() {</div><div>   <span class="m_-6520709161405088222Apple-converted-space"> </span>while garply() {</div><div>     <span class="m_-6520709161405088222Apple-converted-space"> </span>if quux() {</div><div>       <span class="m_-6520709161405088222Apple-converted-space"> </span>break unknown</div><div>     <span class="m_-6520709161405088222Apple-converted-space"> </span>}</div><div>   <span class="m_-6520709161405088222Apple-converted-space"> </span>}</div><div> <span class="m_-6520709161405088222Apple-converted-space"> </span>}</div><div>}</div></blockquote><div><br></div><div>Another downside of the `unexpected case:` spelling is that it doesn&#39;t work as part of a larger pattern. I don&#39;t have a good answer for that one, but perhaps it&#39;s acceptable for now.</div><div><br></div><div>I&#39;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&#39;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&#39;s further out. You can read my revisions at<span class="m_-6520709161405088222Apple-converted-space"> </span><a href="https://github.com/apple/swift-evolution/pull/777" target="_blank">https://github.com/apple/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&#39;s points about versioned libraries / linking semantics of modules.</div><div>- Jason M&#39;s point about migration</div>and I&#39;ll do one more pass over the thread to see if there&#39;s anything else I didn&#39;t address directly. (That doesn&#39;t mean everyone who disagrees, just messages where I think there&#39;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>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-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" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span></div></blockquote></div></div></blockquote></div></div></blockquote></div></div></div></div></div></blockquote></div></blockquote></div></blockquote></div></div></blockquote></div></div>