[swift-evolution] Idea: Support #if os(Darwin) as shorthand for os(iOS) || os(OSX) || os(watchOS) || os(tvOS)

[Joe Groff]

> On Feb 19, 2016, at 4:50 PM, Max Howell via swift-evolution <swift-evolution at swift.org> wrote:
> 
> SwiftPM passes DEBUG and NDEBUG. Ugly, but the standard.

I don't think it's the package manager's place to do that, since the compiler's already aware of the current build mode. IMO all the standard #if flags should ideally be centralized in the language so there isn't a forever-creeping set of conventional -D flags like there are in C land. (Tradition or not, negative flags like NDEBUG should be put out to pasture—we've let go of other, less terrible C traditions.)

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. This means we can compile a function like this down to SIL once:

func assert(@autoclosure _ condition: () -> Bool) {
  if _isDebugAssertConfiguration() && !condition() {
    fatalError()
  }
}

for all of the possible assert behaviors.

-Joe

> 
>> On Feb 19, 2016, at 12:41 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> I've had to reverse all my `#if os`'s because nearly all the code on iOS/watchOS/tvOS is shared, so all my code that *used* to be `#if os(iOS)` is now based on OS X because of that.
>> 
>> I'd very much welcome a larger vocabulary, not to mention picking up debug/release (pretty please)
>> 
>> -- E
>> 
>> 
>>> On Feb 19, 2016, at 12:53 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> I agree that we need something here, but I really like the property we have today that all of the "os" options are mutually exclusive. (Compare: TARGET_OS_IPHONE and TARGET_OS_IOS in <TargetConditionals.h>.) I'd be happy to invent a new predicate for this, though.
>>> 
>>> Other considerations:
>>> - Different Linux distros?
>>> - Common ground across BSDs?
>>> - Unixy? (vs. Windows)
>>> 
>>> And for other platform conditions:
>>> - Architecture subtypes?
>>> - Architecture families? ("32-bit" is a good one.)
>>> 
>>> Jordan
>>> 
>>> 
>>>> On Feb 19, 2016, at 11:19, Kevin Ballard via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> I'd like to see #if support os(Darwin) as shorthand for any Apple platform. This is a lot shorter to type, and it's also future-compatible if Apple ever releases another Darwin-based platform. If os(Darwin) evaluates to true, then `import Darwin` should always work, and presumably `import Foundation` as well.
>>>> 
>>>> 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.
>>>> 
>>>> -Kevin Ballard
>>>> _______________________________________________
>>>> 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
>> 
>> _______________________________________________
>> 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/20160220/83f5de67/attachment.html>