<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="">Back in March, I somewhat foolishly agreed to pick up the gauntlet for a series of community-requested proposals centered on build configurations. Requested items included:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">A way to test for destination platforms like Apple, Linux, Windows, Unix-like, UIKit-supporting, etc</li><li class="">A way to test for Simulator/Emulator vs Hardware targets</li><li class="">A way to test for debug builds</li><li class="">A way to test for platform conditions (bigendian, littlendian, bitwidth 32 and 64, objc-interop, see <font face="Menlo" class="">lib/Basic/LangOptions.cpp</font>)</li></ul><div class=""><br class=""></div></div><div class="">This splintered down into a series of draft proposals. The first adopted proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md" class="">SE-0075</a> adds a build configuration import test similar to Clang's __has_include. It lets you test whether a module like UIKit is available, letting you customize code for specific modules.</div><div class=""><br class=""></div><div class="">Next up on my list is debug-specific coding. Summarizing to date:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">There's a general consensus that a debug state occurs when assertions can fire and are not disabled by compile-time optimizations.</li><li class="">The concept of "debug" is nuanced enough that introducing a single <font face="Menlo" class="">#if debug</font> build configuration test is insufficient for substantial set of community members who interacted in previous discussions and Swift developers who have sent me feedback outside this list.</li><li class="">Conditioning debug on Xcode debug/release schemes is a no-go.</li><li class="">Hidden helper functions already exist in Swift.</li><li class="">Members of the core team believe using build configurations is the wrong point to conditionalize code. </li></ul><div class=""><br class=""></div></div><div class="">Joe Groff wrote, "We specifically avoided making debug/release an #if condition because we considered #if to be the wrong point at which to start conditionalizing code generation for assertions. Though the final executable image's behavior is unavoidably dependent on whether asserts are enabled, we didn't want the SIL for inlineable code to be, since that would mean libraries with inlineable code would need to ship three times the amount of serialized SIL to support the right behavior in -Onone, -O, and -Ounchecked builds. Instead, the standard library has some hidden helper functions, _isDebugAssertConfiguration, _isReleaseAssertConfiguration, and _isFastAssertConfiguration, which are guaranteed to be constant-folded away before final code generation."</div><div class=""><br class=""></div><div class="">My pitch: I want to promote these three helper functions to the standard library and remove their underscore prefixes. My primary use case is to limit logging and development-servicing functions (for example, statistical measurements) to "debug" builds. I believe a sufficient quorum of the community has similar needs that would be served by making these first class "listed" functions.</div><div class=""><br class=""></div><div class="">Doing so:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">Eliminates the build configuration approach</li><li class="">Eliminates the need to define what "debug" means</li><li class="">Conditions configuration testing on assertion firing state not Xcode schemes or build flags (e.g. -D debug)</li><li class="">Uses already-existing global functions, requiring no coding</li></ul><div class=""><br class=""></div></div><div class="">Thoughts?</div><div class=""><br class=""></div><div class="">-- E</div><div class="">p.s. I'd warmly welcome any third party assistance with the outstanding requests</div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>