<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Well you have described it perfectly. :)</div><div id="AppleMailSignature">It is indeed default: fatalError() and default: break in one character. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">On the other hand I have fear that we will overwhelm language semantic with ! and ? everywhere. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">So, do you think this ability to tweak compiler behavior and save one line of code is valuable?</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Will be interesting to see some statistics of using different default cases. </div><div><br>13 февр. 2016 г., в 20:36, Ross O'Brien <<a href="mailto:narrativium+swift@gmail.com">narrativium+swift@gmail.com</a>> написал(а):<br><br></div><blockquote type="cite"><div><div dir="ltr"><div>So...</div><div><br></div><div>Our basic 'switch' takes an expression and tries to match it to the first matching case (with programmer option to 'fallthrough'. The compiler runs an extra routine to check we covered every situation, but as far as I know, it's only sure in cases of booleans and enums. In all other situations the compiler requires a 'default' case.</div><div><br></div><div>The proposed 'switch!' says: the programmer overrules the compiler. Don't require a default case, the provided cases cover everything, yes we're sure, crash if not. It's 'default: fatalError()' in one character.</div><div><br></div><div>I'm not sure what 'switch?' ought to do. If I understand you right, you're suggesting that 'switch?' be 'default: break' in one character. I think that might have merit, but I also think the compiler would still have to do its checks, because in this case:</div><div>'let x : Foo</div><div>switch? y</div><div>{</div><div> case z: x = Foo()</div><div> case ...: ...</div><div> ...</div><div>}'</div><div>If the compiler doesn't think it can find a matching case for y, then Swift can't be sure that x has a value. That should still have a warning.</div><div><br></div><div>If I haven't understood you, please clarify.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 12, 2016 at 7:06 PM, Алексей Демедецкий <span dir="ltr"><<a href="mailto:demedeckie@gmail.com" target="_blank">demedeckie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">+1 for this switch behavior. Can we also treat switch? as one with did not require default checking?<br>
<span class=""><br>
> I have a suggestion.<br>
> Suppose we think of 'switch' as being like a non-optional type. The compiler does its thing and tries to ensure that the switched expression will match something, and enforces a default if it cannot verify a matching state.<br>
> Could we force the switch? i.e. suffix the 'switch' keyword with an exclamation mark, to say: the programmer insists that one of these cases will match; there's no need for a default case, but if nothing matches then crash.<br>
><br>
> For example:<br>
> let x:Int<br>
> switch! expression<br>
> {<br>
> case ... { x = 1 }<br>
> case ... { x = 2 }<br>
> // no default. the ! signifies that the app should crash if none of these cases matches the expression<br>
> }<br>
><br>
><br>
><br>
><br>
</span>> On Fri, Feb 12, 2016 at 5:32 PM, Chris Lattner via swift-evolution<<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>(mailto:<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>)>wrote:<br>
<span class="">> > On Feb 12, 2016, at 9:27 AM, Amir Michail<<a href="mailto:a.michail@me.com">a.michail@me.com</a>(mailto:<a href="mailto:a.michail@me.com">a.michail@me.com</a>)>wrote:<br>
> > >>><br>
> > >>>What’s wrong with having the compiler explicitly check for “false”?<br>
> > >><br>
> > >>Weird special cases make the compiler less predictable.<br>
> > ><br>
> > >True, but not having them requires deeper knowledge of the standard libraries.<br>
> > ><br>
> > >In practice, just checking for “false” would solve this problem.<br>
> ><br>
</span>> > That is not what you’re actually proposing.You are proposing that the compiler encode special knowledge of the precondition *library function* into the compiler, and teach it about a single special case.We don’t like the compiler to have special cases like this for a large number of reasons, in particular, if we did this, someone would file a bug asking for *their* equivalent reimplementation of precondition to have the same magic blessed behavior.<br>
> ><br>
> > This is a slippery slope that leads to a lot of complexity downstream, it is better to keep the compiler simple and predictable.Also, as other people have pointed out, this has already been solved for you: just use preconditionFailure.<br>
<span class="">> ><br>
> > -Chris<br>
> > _______________________________________________<br>
> > swift-evolution mailing list<br>
</span>> > <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>(mailto:<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/mailman/listinfo/swift-evolution</a><br>
><br>
><br>
> </blockquote></div><br></div>
</div></blockquote></body></html>