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

[Erica Sadun]

I would like to bring the compiler directive discussion back to life. Introducing new conditionals 
has been raised at several points, poked at, and then died down and gone nowhere.

Discussed at a variety of times directives mentioned on-list include

Apple/Non-Apple Platform to differentiate imports. The current art allows if os(Linux) but does not categorize Apple platforms as an entire coherent group. #if os(Darwin) // os(iOS) || os(OSX) || os(watchOS) || os(tvOS), expandable for any new OS's. Kevin Ballard writes, "Without this, I think people are going to be tempted to write if !os(Linux) instead of writing out all 4 Apple platforms, and this is unfortunate because it makes the assumption that Linux is the only non-Apple platform, and that's simply not true."
Common UIKit platform: #if os(iOS) || os(tvOS) or general module availability: #if available(AppKit), #if available(UIKit) (Plus a proposal to replace os with platform) ("Is the target a common UIKit platform? Can it import UIKit?")
Linux distribution check ("Is this target a specific Linux distro? Is it at least this distro or later?")
Is this a Unixy-platform (vs, for example, running on Windows would not be)
What BSD characteristics does this platform support?
Simulator/Physical destinations ("Is the target a simulator environment or physical device?")
Debug/Release builds (bypassing the need for -DDEBUG flags) ("Is the target in Debug or Release mode?")
DebugAsserts/ReleaseAsserts/FastAsserts
General conditional flag detection #if config(Debug)
Test-supporting ("Is the target built for running tests?)
Big-or-little endian
Architecture families: Is this a 32-or-64-bit target
Architecture subtypes
Signed-or-unsigned char
Existing build configurations include os() (OSX, iOS, watchOS, tvOS, Linux) and arch() (X86_64, arm, arm64, i386), the literals true and false, and testing for command-line flags defined using -D <#flag#>.

I believe these directives involve relatively minor changes, should be easy to implement, and 
can be extended over time as needed. It would probably be best to get a sense of which 
ones the dev community *really* want and need  and push on those to avoid clutter, 
but I’d hate to see these languish without getting a proper discussion.

Core team members: Would it best to propose individual changes, 
create a small groups of related items, or try to push through a large suite?

-- E

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160310/e0528119/attachment.html>