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

[Step C]

Agreed, thanks for tracking this, Erica. I want to see this move forward. 

I'd personally like to see:
- os(darwin) or Apple platform grouping
- simulator vs physical device
- test supporting
- module / UIKit availability

- Step

> On Mar 10, 2016, at 9:26 PM, William Dillon via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Thanks for this, Erica.  A huge +1 from me.
> 
> - Will
> 
>> On Mar 10, 2016, at 6:15 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 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
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> 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/20160311/7ca22adc/attachment.html>