[swift-evolution] [Pitch] Expose assert configuration functions in standard library

[Jacob Bandes-Storch]

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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160529/6508d8b1/attachment.html>