<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 20, 2016, at 6:05 PM, Max Howell <<a href="mailto:max.howell@apple.com" class="">max.howell@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 20, 2016, at 5:39 PM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Feb 19, 2016, at 4:50 PM, Max Howell 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=""><div class="">SwiftPM passes DEBUG and NDEBUG. Ugly, but the standard.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">I don't think it's the package manager's place to do that, since the compiler's already aware of the current build mode.</div></div></div></blockquote><div class=""><br class=""></div><div class="">It can be reverted.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="">IMO all the standard #if flags should ideally be centralized in the language so there isn't a forever-creeping set of conventional -D flags like there are in C land. (Tradition or not, negative flags like NDEBUG should be put out to pasture—we've let go of other, less terrible C traditions.)</div></div></div></blockquote><div class=""><br class=""></div><div class="">This one seemed different, since SwiftPM has explicit debug and release modes for compilation.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="">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. This means we can compile a function like this down to SIL once:</div><div class=""><br class=""></div></div><blockquote class="" style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px 0px 0px 40px; border: none; padding: 0px;"><div class=""><div class="">func assert(@autoclosure _ condition: () -> Bool) {</div><div class=""> if _isDebugAssertConfiguration() && !condition() {</div><div class=""> fatalError()</div><div class=""> }</div><div class="">}</div></div></blockquote><div style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><br class=""></div><div class="">for all of the possible assert behaviors.</div></div></div></blockquote><br class=""></div><div class="">Makes sense, I can revert it. But this is something people will be asking for pretty regularly, so I’ll forward their requests to your email ;)</div></div></div></blockquote><br class=""></div><div>They're welcome to start evolution threads! I'll add that, in our original grand vision for compiler flags before the reality of shipping got in the way, it would have been possible to use flags both to conditionalize compilation, similar to #if in C-family languages, but also as expressions, for conditionalization during code generation, which would allow for either:</div><div><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div>#if config(Debug)</div><div>func debugTrap() { fatalError() }</div><div>#else</div><div>func debugTrap() { /*do nothing*/ }</div><div>#endif</div><div><br class=""></div></blockquote>or:<div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">func assert(...) {</div><div class=""> if #config(Debug) {</div><div class=""> fatalError()</div><div class=""> }</div><div class="">}</div><div class=""><br class=""></div></blockquote>and we would have encouraged the latter where possible, since it would allow for more sharing of build products across build configurations. #if-style conditionalization is unavoidable if you need to conditionally import frameworks that are only available on specific platforms, but the 'if #' approach allows for more efficient cross-platform, cross-configuration builds and lets the compiler more eagerly check semantics without fully depending on execution tests on every target platform.<div class=""><br class=""></div><div class="">-Joe</div></body></html>