Am I understanding correctly that -Onone → _isDebugAssertConfiguration is true -O → _isReleaseAssertConfiguration is true -Ounchecked → _isFastAssertConfiguration is true
? If the goal is to expose the optimization level to user code, might I suggest something like enum OptimizationLevel { case none case standard case unchecked } var optimizationLevel: OptimizationLevel { get } 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. On Sun, May 29, 2016 at 10:59 AM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > 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: > > > - A way to test for destination platforms like Apple, Linux, > Windows, Unix-like, UIKit-supporting, etc > - A way to test for Simulator/Emulator vs Hardware targets > - A way to test for debug builds > - A way to test for platform conditions (bigendian, littlendian, > bitwidth 32 and 64, objc-interop, see lib/Basic/LangOptions.cpp) > > > This splintered down into a series of draft proposals. The first adopted > proposal, SE-0075 > <https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md> > 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. > > Next up on my list is debug-specific coding. Summarizing to date: > > > - There's a general consensus that a debug state occurs when > assertions can fire and are not disabled by compile-time optimizations. > - The concept of "debug" is nuanced enough that introducing a single #if > debug 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. > - Conditioning debug on Xcode debug/release schemes is a no-go. > - Hidden helper functions already exist in Swift. > - Members of the core team believe using build configurations is the > wrong point to conditionalize code. > > > 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." > > 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. > > Doing so: > > > - Eliminates the build configuration approach > - Eliminates the need to define what "debug" means > - Conditions configuration testing on assertion firing state not Xcode > schemes or build flags (e.g. -D debug) > - Uses already-existing global functions, requiring no coding > > > Thoughts? > > -- E > p.s. I'd warmly welcome any third party assistance with the outstanding > requests > > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution