<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 Oct 5, 2016, at 8:29 AM, Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> 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; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 4 Oct 2016, at 16:30, Tim Vermeulen via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> 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; -webkit-line-break: after-white-space;" class="">I think I agree with you. The postfix `!` operator is always shorthand for `fatalError()` (and some more syntax), and it would fit nicely with `default: fatalError()`.<div class=""><br class=""></div><div class="">The Swift usage of `?` is indeed different than `default: break` would do, so `switch?` wouldn’t convey the right message. I hadn’t given it enough thought. I still think a shorthand for `default: break` would be _nice_, but it surely shouldn’t change the `?` consistency, it also shouldn’t replace the current `switch` (as exhaustiveness is very useful) and it’s probably not worth introducing new syntax for.</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 4 Oct 2016, at 16:36, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">There is a plausible argument for `switch!`, because it is not possible for the compiler to prove exhaustiveness in all circumstances where you might know it to be the case.<br class=""><br class="">However, I'd be very against `switch?`: it undermines the exhaustiveness guarantee of the switch statement and is wholly inconsistent with Swift usage of `?`, which indicates the possibility of an Optional. We simply don't need a new spelling for `default: break`.</div></blockquote></div></div></div></div></blockquote><br class=""></div><div class="">I agree with Tim; I'm a +1 for switch! for a convenient means of erroring out, but I think switch? is a bit too different from normal usage of the question-mark.</div><div class=""><br class=""></div><div class="">One other alternative might be if there could be some kind of switch else syntax, kind of like a guard statement, allowing options on what to do? Only problem is how best to structure it, as the use of break might confusing as to its scope, like so:</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>switch(foo) else break { // Break from the switch, or the enclosing block?</font></div><div class=""><br class=""></div><div class="">So I'm not 100% on that. But it would mean that switch! would be a shorthand for switch else fatalError().</div></div></div></blockquote><br class=""></div><div>I will courteously jump in with a -1 for both switch! and switch?. I get how pretty they are at first glance: they have symmetry with existing constructs. However:</div><div><br class=""></div><div>* I doubt they'll be used much and I don't think something should be added to the language without measurable and consequential benefits.</div><div><br class=""></div><div>* I don't think </div><div><br class=""></div><div> `default: fatalError() // this should never happen, cases are exhaustive` </div><div><br class=""></div><div>is a burden to type, in fact, I like how self-documenting it is, even if the compiler sometimes guesses wrong -- in fact, I think the compiler *should* guess wrong, especially on especially oddball case sets like `(.min ..< 0)` and `(0 ... .max)`, let alone cases where you only want the even values within those ranges.</div><div><br class=""></div><div>* I do think that visually scanning for switch variants places a burden on code readability. Unlike try? and try!, the switch!? statement will likely be lines and lines away from where it impacts code. The place that best means "this should never happen, cases are exhaustive" is the default case.</div><br class=""><div class="">-- E</div><div class=""><br class=""></div></body></html>