<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 4, 2018, at 10:31 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div style="font-family: Helvetica; font-size: 12px; 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; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_quote"><div dir="auto" class=""><br class="Apple-interchange-newline">On Fri, Jan 5, 2018 at 00:21 Cheyo Jimenez <<a href="mailto:cheyo@masters3d.com" class="">cheyo@masters3d.com</a>> wrote:<br class=""></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" class=""><div class=""></div><div class=""><br class=""></div><div class="">On Jan 4, 2018, at 4:37 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><div class="gmail_quote"><div dir="auto" class="">On Thu, Jan 4, 2018 at 19:29 Cheyo J. Jimenez <<a href="mailto:cheyo@masters3d.com" target="_blank" class="">cheyo@masters3d.com</a>> wrote:<br class=""></div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">We seem to agree that, by virtue of not supporting use in a pattern and being placed at the end, the feature is a flavor of default. I’m still not sure I understand why you believe it should not be a flavor of default going forward.</div><div dir="auto" class=""><br class=""></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 style="word-wrap: break-word;" class=""><div class=""><div class=""></div></div></div><div style="word-wrap: break-word;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><div class="gmail_quote"><div dir="auto" class=""><br class=""></div><div dir="auto" class="">You still haven’t answered my question, though—what’s the use case for the feature you propose?</div></div></div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap: break-word;" class=""><div class="">My use case would be distinguishing between compile time known cases vs “future only” cases (or unknown cases).</div></div></blockquote><div dir="auto" class=""><br class=""></div><div dir="auto" class="">I understand that the feature you propose would allow you to make such a distinction, but again, what is your use case for doing so?</div></div></div></div></blockquote><div class=""><br class=""></div></div><div dir="auto" class="">Breaking out early by checking unknown cases first. I admit this is not deal breaker, just a different style I’d like to see supported in the future. </div></blockquote><div dir="auto" class=""><br class=""></div><div dir="auto" class="">I'm still not sure I understand. How can the machine know that it's dealing with an unknown case without first checking if it matches any known case?</div></div></div></div></blockquote></div><br class=""><div class="">I had the same thought as Cheyo. It isn’t a deal breaker… I like the compromise, but I would prefer it trigger only on an actual unknown case (as opposed to acting like default). I like to break failure cases out at the top when possible. I don’t see any good reason not to support that style.</div><div class=""><br class=""></div><div class="">To answer your question, in the naive sense, it basically is the same question as asking if it is a known case (and then taking the inverse). That doesn’t mean actually checking each case separately though. For example, if the enum cases are internally represented as an unsigned integer, and they are all together in a block, the compiler could simply check that it is greater than the max known value. You could probably even do a bit mask comparison in some cases...</div><div class=""><br class=""></div><div class="">If it is inefficient for some reason, the compiler should be free to rearrange the order of things, as long as it doesn’t change the outcome.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon </div></body></html>