<div dir="ltr">Am I understanding correctly that<div><br></div><div> -Onone → <span style="font-size:12.8px">_isDebugAssertConfiguration is true</span></div><div><span style="font-size:12.8px"> -O → _isReleaseAssertConfiguration is true</span></div><div><span style="font-size:12.8px"> -Ounchecked → _isFastAssertConfiguration is true</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">?</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">If the goal is to expose the optimization level to user code, might I suggest something like</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"> enum OptimizationLevel {</span></div><div><span style="font-size:12.8px"> case none</span></div><div><span style="font-size:12.8px"> case standard</span></div><div><span style="font-size:12.8px"> case unchecked</span></div><div><span style="font-size:12.8px"> }</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"> var optimizationLevel: OptimizationLevel { get }</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">IMO, users may still want to control certain things with per-configuration flags, but that's still achievable with -DX and #if X. Exposing the optimization level makes sense to me.</span></div><div class="gmail_extra">
<br><div class="gmail_quote">On Sun, May 29, 2016 at 10:59 AM, Erica Sadun via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>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><br></div><div><ul><li>A way to test for destination platforms like Apple, Linux, Windows, Unix-like, UIKit-supporting, etc</li><li>A way to test for Simulator/Emulator vs Hardware targets</li><li>A way to test for debug builds</li><li>A way to test for platform conditions (bigendian, littlendian, bitwidth 32 and 64, objc-interop, see <font face="Menlo">lib/Basic/LangOptions.cpp</font>)</li></ul><div><br></div></div><div>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" target="_blank">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><br></div><div>Next up on my list is debug-specific coding. Summarizing to date:</div><div><br></div><div><ul><li>There's a general consensus that a debug state occurs when assertions can fire and are not disabled by compile-time optimizations.</li><li>The concept of "debug" is nuanced enough that introducing a single <font face="Menlo">#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>Conditioning debug on Xcode debug/release schemes is a no-go.</li><li>Hidden helper functions already exist in Swift.</li><li>Members of the core team believe using build configurations is the wrong point to conditionalize code. </li></ul><div><br></div></div><div>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><br></div><div>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><br></div><div>Doing so:</div><div><br></div><div><ul><li>Eliminates the build configuration approach</li><li>Eliminates the need to define what "debug" means</li><li>Conditions configuration testing on assertion firing state not Xcode schemes or build flags (e.g. -D debug)</li><li>Uses already-existing global functions, requiring no coding</li></ul><div><br></div></div><div>Thoughts?</div><span><font color="#888888"><div><br></div><div>-- E</div></font></span><div>p.s. I'd warmly welcome any third party assistance with the outstanding requests</div><div><br></div><div><br></div></div><br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div></div>