<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I was playing around with Swift's mysterious Builtin module, accessible via the `-parse-stdlib` compiler flag and I noticed a builtin primitive that causes a fatal error if the branch it's in is not optimized away. This seems like an opportunity for a much more powerful "this place is not implemented", where the execution branch analyzer can determine at compile time for specific cases whether or not the unimplemented branch will be accessed. We could make a proposal to introduce a new compiler directive of the following form:<div class=""><br class=""></div><div class="">public func #unavailable(_ message: String? = nil) -> Never</div><div class=""><br class=""></div><div class="">This directive would be allowed both in function scope and global scope.</div><div class="">Calls to this directive would generate a compile-time error when the execution path it's located in can be guaranteed and a run-time error in all other cases.</div><div class=""><div>Placing this directive in the global scope would generate a compile-time error unconditionally.</div><div><br class=""></div><div>The only way to avoid this error is to either have the call to it optimized away or conditionally compiled out:</div><div><br class=""></div><div>#if os(macOS)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>import Cocoa</div><div>#else</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>#unavailalbe("Sorry, pal. I only work with macs.")</div><div>#endif</div><div><br class=""></div><div>func compare(_ x: Int, _ y: Int) -> Int {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>if x > 0 {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>return 1</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>} else if x == 0 {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>return 0</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>} else if x < 0 {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>return -1</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>} else {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>#unavailable("How the hell did you managed to get here?")</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div>}</div><div><br class=""></div><div><blockquote type="cite" class=""><div class="">On Jun 11, 2017, at 7:45 PM, Javier Soto 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="">+1 on adding a compile-time error directive. #error seems like the right syntax as well.<br class="">I had a maybe nit-picky comment about the proposal though. I think the example may not be ideal, since you could accomplish that compile-time error by annotating the method or class where that code lives with @available(tvOS) , no?<br class=""><div class="gmail_quote"><div dir="ltr" class="">On Sun, Jun 11, 2017 at 9:18 AM Will Field-Thompson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">This is the best I've found for searching the archives: <a href="https://www.google.com/search?q=site%3Ahttps%3A%2F%2Flists.swift.org%2Fpipermail%2Fswift-evolution%2F+%22%23error%22" target="_blank" class="">https://www.google.com/search?q=site%3Ahttps%3A%2F%2Flists.swift.org%2Fpipermail%2Fswift-evolution%2F+%22%23error%22</a><div class=""><br class=""></div><div class=""><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Sun, Jun 11, 2017 at 11:30 AM Daryle Walker via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="">
> On Jun 10, 2017, at 2:00 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:<br class="">
><br class="">
> Daryle, there have been several pitches in the past with respect to #error, and very enlightening arguments both for and against the idea have been eloquently written.<br class="">
><br class="">
> Since you’re resurrecting this idea, could I suggest going back through the archives and linking to and summarizing these arguments, so that we’re not restarting the discussion from scratch? :)<br class="">
<br class="">
Is there somewhere to search the archives?<br class="">
<br class="">
—<br class="">
Daryle Walker<br class="">
Mac, Internet, and Video Game Junkie<br class="">
darylew AT mac DOT com<br class="">
<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="">
</blockquote></div>
_______________________________________________<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="">
</blockquote></div><div dir="ltr" class="">-- <br class=""></div><div data-smartmail="gmail_signature" class=""><div dir="ltr" class="">Javier Soto</div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>