<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 Feb 12, 2016, at 12:56 PM, Ross O'Brien <<a href="mailto:narrativium+swift@gmail.com" class="">narrativium+swift@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Okay, but the original general problem was that you wanted to ensure that one of the cases applied, and my suggestion addressed that problem.<div class=""><br class=""></div><div class="">Since then it's become whether or not the developer has knowledge of fatalError(), preconditionFailure(), and then the more general 'precondition'. It seems to me that the compiler clearly does have some boolean evaluation routine in place, or 'if false { ... }' wouldn't generate the 'this will never be executed' warning I mentioned earlier, and perhaps this routine could be applied to precondition calls as well.</div><div class=""><br class=""></div><div class="">Providing a way for me to issue warnings for suboptimal use of APIs I write is a third thing entirely.</div></div></div></blockquote><div><br class=""></div><div>It would also provide a solution to this problem in particular.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Feb 12, 2016 at 5:45 PM, Amir Michail <span dir="ltr" class=""><<a href="mailto:a.michail@me.com" target="_blank" class="">a.michail@me.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Feb 12, 2016, at 12:41 PM, Ross O'Brien <<a href="mailto:narrativium+swift@gmail.com" target="_blank" class="">narrativium+swift@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">I have a suggestion.<div class="">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.</div><div class="">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.</div><div class=""><br class=""></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">This doesn’t solve the more general problem <font size="2" class="">— namely, that of required deep knowledge of the standard libraries.</font></div><div class=""><font size="2" class=""><br class=""></font></div><div class=""><font size="2" class="">A more general solution would be to provide a way for API writers to issue (heuristic) warnings for suboptimal usage of their APIs.</font></div><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">For example:</div><div class=""><span style="font-size:13px" class="">let x:Int</span></div><div class="">switch! expression</div><div class="">{</div><div class=""> case ... { x = 1 }</div><div class=""> case ... { x = 2 }</div><div class=""> // no default. the ! signifies that the app should crash if none of these cases matches the expression</div><div class="">}<br class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Feb 12, 2016 at 5:32 PM, Chris Lattner via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Feb 12, 2016, at 9:27 AM, Amir Michail <<a href="mailto:a.michail@me.com" target="_blank" class="">a.michail@me.com</a>> wrote:<br class="">
>>><br class="">
>>> What’s wrong with having the compiler explicitly check for “false”?<br class="">
>><br class="">
>> Weird special cases make the compiler less predictable.<br class="">
><br class="">
</span>> True, but not having them requires deeper knowledge of the standard libraries.<br class="">
><br class="">
> In practice, just checking for “false” would solve this problem.<br class="">
<br class="">
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 class="">
<br class="">
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 class="">
<div class=""><div class=""><br class="">
-Chris<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</div></div></blockquote></div><br class=""></div>
</div></blockquote></span></div><br class=""></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>