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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
