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

Max Howell max.howell at apple.com
Sat Feb 20 20:05:56 CST 2016

> On Feb 20, 2016, at 5:39 PM, Joe Groff <jgroff at apple.com> wrote:
>> On Feb 19, 2016, at 4:50 PM, Max Howell via swift-evolution <swift-evolution at swift.org <mailto: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.

It can be reverted.

> 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.)

This one seemed different, since SwiftPM has explicit debug and release modes for compilation.

> 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.

Makes sense, I can revert it. But this is something people will be asking for pretty regularly, so I’ll forward their requests to your email ;)

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

More information about the swift-evolution mailing list