<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Or, to be honest:</div><div class=""><br class=""></div><div class=""><div class=""><font face="Menlo" class="">/// Offers user-facing public assert configuration test</font></div><div class=""><font face="Menlo" class="">@_transparent</font></div><div class=""><font face="Menlo" class="">public</font></div><div class=""><font face="Menlo" class="">func isDebugAssertConfiguration() -&gt; Bool {</font></div><div class=""><font face="Menlo" class="">&nbsp; return _isDebugAssertConfiguration()</font></div><div class=""><font face="Menlo" class="">}</font></div></div><div class=""><br class=""></div><div class="">which covers, I believe, about 98% of the demand for this feature</div><div class=""><br class=""></div><div class="">-- E</div><br class=""><div><blockquote type="cite" class=""><div class="">On May 31, 2016, at 11:21 PM, Brent Royal-Gordon &lt;<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class="">My pitch: I want to promote these three helper functions to the standard library and remove their underscore prefixes.<br class=""></blockquote><br class="">These functions currently have implementations like this:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre">        </span>@_transparent<br class=""><span class="Apple-tab-span" style="white-space:pre">        </span>@warn_unused_result<br class=""><span class="Apple-tab-span" style="white-space:pre">        </span>public // @testable<br class=""><span class="Apple-tab-span" style="white-space:pre">        </span>func _isDebugAssertConfiguration() -&gt; Bool {<br class=""><span class="Apple-tab-span" style="white-space:pre">        </span> &nbsp;// The values for the assert_configuration call are:<br class=""><span class="Apple-tab-span" style="white-space:pre">        </span> &nbsp;// 0: Debug<br class=""><span class="Apple-tab-span" style="white-space:pre">        </span> &nbsp;// 1: Release<br class=""><span class="Apple-tab-span" style="white-space:pre">        </span> &nbsp;// 2: Fast<br class=""><span class="Apple-tab-span" style="white-space:pre">        </span> &nbsp;return Int32(Builtin.assert_configuration()) == 0<br class=""><span class="Apple-tab-span" style="white-space:pre">        </span>}<br class=""><br class="">I think how this works is:<br class=""><br class="">* @_transparent makes sure these functions are always inlined at the call site.<br class="">* Most things in the standard library are *also* @_transparent.<br class="">* Therefore, after both (or more!) inlinings happen, you get the `Builtin.assert_configuration()` of the code calling into the standard library.<br class=""><br class="">Needless to say, this is *extremely* weird and magical, and I'm skeptical of the idea that we should expose it as a normal function call.<br class=""><br class="">I think a better design which would accurately convey its magic is to add a type to the standard library:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre">        </span>enum BuildKind: Int32 { case debug, release, unchecked }<br class=""><br class="">(Note: the names in this could use some bikeshedding. Put that aside.)<br class=""><br class="">And then add a `#buildKind` compiler substitution which is equivalent to:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre">        </span>BuildKind(rawValue: Int32(Builtin.assert_configuration()))<br class=""><br class="">Now you can surround your debug-only code with `#buildKind == .debug`. Or you can capture the *call site's* build kind with a default parameter:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre">        </span>func log(_ message: String, level: LogLevel = .info, buildKind: BuildKind = #buildKind)<br class=""><br class="">Even the standard library might be able to do this if it wanted to, allowing your code to enable or disable asserts based on whether your caller's code is in debug mode or not:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre">        </span>func assert(@autoclosure condition: () -&gt; Bool, @autoclosure _ message: () -&gt; String = default, file: StaticString= #file, line: UInt = #line, buildKind: BuildKind = #buildKind)<br class=""><br class="">(I wouldn't suggest that every stdlib member add such a default parameter; most should continue to rely on `@_transparent`. But I think that could be useful for calls like `assert()` and `precondition()`.<br class=""><br class="">-- <br class="">Brent Royal-Gordon<br class="">Architechies<br class=""><br class=""></div></div></blockquote></div><br class=""></body></html>