[swift-evolution] [META] Re-invigorating the compiler directive discussion

Step C schristopher at bignerdranch.com
Sat Mar 12 22:25:44 CST 2016

Comments below

> On Mar 12, 2016, at 10:56 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
> Here's a first draft.
> Start kicking away:
> Expanding Build Configuration Tests
> Proposal: SE-00XX
> Author(s): Erica Sadun
> Status: TBD
> Review manager: TBD
> Introduction
> Expanding the configuration test suite to include Darwin support (to test for Apple platforms) was first introduced on the Swift-Evolution list by Kevin Ballard. His idea was greeted warmly and quickly expanded upon by developers looking to introduce the kinds of conditional configuration they're used to in other languages. This proposal introduces a subset of the configurations requested on that thread.
> SE-0020 added #if swift to enable code to compile with specific versions of the Swift language. This proposal introduces several further compile-time configuration, adding configuration tests for x, y, z, and w.
I assume x, y, z, and w are intended to be filled in once the list has settled. 

> This proposal was discussed on-list in the thread.
> Current Art
> Swift currently supports the following configuration tests:
> The literals true and false
> The os() function that tests for OSX, iOS, watchOS, tvOS, and Linux
> The arch() function that tests for x86_64, arm, arm64, and i386
> The swift() function that tests for specific Swift language releases, e.g. swift(>=2.2)
> Motivation
> As Swift expands to a growing developer base and to new platforms, the existing suite of configuration tests begins to show strain. Shortcuts taking advantage of current limitations introduce fragility. For example, testing #if os(iOS) || os(OSX) || os(watchOS) || os(tvOS) may miss new platform targets and #if !os(Linux) may introduce errors should Swift extend to other non-Apple platforms, such as Windows.
> Swift also misses a built-in #if debug test. Although you can specify command-line flags using -D <#flag#> (e.g. -D debug) and test in-code (#if debug), there's no consistent system-supplied way to perform this test.
What do you mean by "this test"? Testing for a built-in configuration (debug) without needing customization?

 Also FWIW I am ok with the custom flag approach.( In fact it just occurred to me that I can use the custom flags approach to check for test targets too - nice! )

> This proposal introduces a minimal set of utility configuration tests.
> Detail Design
> #if platform(Apple) tests for platform families, including Apple, Linux, Unix, Windows
> #if imports(UIKit) tests for framework support, differentiating, for example, Mac code from iOS and tvOS code.
Am I reading it right that this would import the framework if the test succeeds?

> #if target(simulator) and #if target(device) represent a common categorization requirement, such as Metal, Keychain, and AVFoundation Camera code. 
> #if target(32bit) and #if target(64bit) tests for 32 and 64 bit architecture families. 
> #if target(bigendian) and #if target(littleendian) tests for big and little endianness.
> #if config(debug) tests for debug builds. 
Wondering if it is better to cover these all in one proposal or chunk them up. Wouldn't want this to become an omnibus proposal and get bogged down. But it makes sense to discuss many of these together. 
> Note
> Joe Groff writes, "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." 
> Not included in this proposal at this time: "Is the target built for running tests", #if destination() tests for specific destinations, #if destination(BSD), #if destination(Ubuntu, >=14.04) to establish common-ground calls for, for example, BSD destinations or specific Linux distros.
> Alternatives Considered
> There are no alternatives considered.
> _______________________________________________
> 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/20160312/936cb2e4/attachment.html>

More information about the swift-evolution mailing list