The Swift team give an impeccable impression of a group of people who’ve never actually tried to use Swift.

An incredibly basic compiler task is to provide code a way to distinguish between debug & release builds, in order that it can behave accordingly (e.g. change the default logging verbosity, change asserts from fatal to non-fatal, etc).

Long story short there is no way to do this that works correctly with swift build.

You can make it work with Xcode only by way of a simple workaround – you manually define a custom Swift flag in your target’s settings (here’s one of a bajillion explanations of how do this).  You end up with basically identical code to other C-family languages, e.g.:

#if DEBUG
    let logVerbosity = 1
#else
    let logVerbosity = 0
#endif

But there is no way, when using swift build, to specify custom Swift flags in your package config.

You can specify them manually with every single swift build invocation, e.g.:

swift build -c debug -Xswiftc '-DDEBUG'

But now you have extra work and the possibility of screwing it up (e.g. omitting the flag, or mismatching it to your actual build style).

The closest you can get is to use some undocumented, hidden Swift internal library functions:

func _isDebugAssertConfiguration() -> Bool
func _isFastAssertConfiguration() -> Bool

These are defined in swift/stdlib/public/core/AssertCommon.swift.

Only the first is likely to be useful.  The second applies in the case where you’re building not just for release but unchecked (-Ounchecked).  If you just want to conditionalise on release builds generally, you have to do !_isDebugAssertConfiguration().

The additional problem with this approach is that these are then, in your code, runtime checks.  And the compiler then thinks it’s being helpful by pointing out that some of your code that uses them is unreachable.

And of course Swift has absolutely no way to silence compiler warnings, or otherwise tell the compiler not to trust its reachability checks.

Sigh.

Update (February 2018)

While the above method – using the _isDebugAssertConfiguration() method – does still work at time of writing, in Swift 4.1, there are some marginally better ways now available.  There’s still not a proper solution, infuriatingly, but with some creativity, as you’ll see momentarily, you can get pretty close to expected functionality.

First alternative

This will only suit some cases, but its relative cleanliness & simplicity makes it appealing when it is an option.

You can use #if targetEnvironment(simulator).  This of course only distinguishes between the simulator and a real iDevice environment, though that can often be useful too, perhaps orthogonally to DEBUG vs RELEASE concepts.

Second alternative

Wrap all uses of _isDebugAssertConfiguration() inside a minimal set of functions.  All this gets you is a reduced (and fixed) number of unreachable code warnings, though.

For example:

func inDebugBuilds(_ code: () -> Void) {
    if _isDebugAssertConfiguration() {
        code()
    }
}

func inReleaseBuilds(_ code: () -> Void) {
    if !_isDebugAssertConfiguration() {
        code()
    }
}

You can then use these in a fairly streamlined way:

inDebugBuilds {
    print("Hello, I only greet in debug builds!")
}

inReleaseBuilds {
    print("While I only greet in release builds - aloha!")
}

Third alternative

It’s possible to do one better than the above, and eliminate those unreachable code warnings entirely.  Plus, doing so actually removes any use of unofficial APIs… but it requires abusing the official API a bit.

The built-in assert() method is implemented atop _isDebugAssertConfiguration() just the same as inDebugBuilds() is, above.  However, because it’s part of the Swift standard library, you don’t have to be concerned about its implementation, its use of private / undocumented language, compiler, or library features – that’s up to the Swift compiler team.  Most importantly, use of it in your code doesn’t emit an unreachable code warning.

So we can do something like:

func inDebugBuilds(_ code: () -> Void) {
    assert({ code(); return true }())
}

Ugly and obtuse, but functional and reasonably expected to work in all future versions of Swift.

You can similarly create a variant for release-build-only code, though it’s even hackier:

func inReleaseBuilds(_ code: () -> Void) {
    var skip: Bool = false
    assert({ skip = true; return true }())

    if !skip {
        code()
    }
}

Icky, but it works.  On the upside, you only have to define this ugliness in one place in your module, and then you can try to forget about its implementation. 😝

One caveat is that I don’t know if the above approach will properly strip out the unreachable code from your built binaries.

Another caveat with these is that since you’re invoking a function, you can’t do a natural if … else … pattern – instead you need explicit, distinct inDebugBuilds & inReleaseBuilds blocks.  So it can’t be completely like the vanilla #if DEBUG … #else … that C-family languages have had since before the dinosaurs.  You could create versions that take two closures as parameters – one for the affirmative case, one for the other… the trade-off is that your invocations are then a little more verbose and obviously function-cally, e.g.:

func forBuildStyle(debug debugCode: () -> Void,
                    release releaseCode: () -> Void) {
    var debugBuild: Bool = false
    assert({ debugBuild = true; return true }())

    if debugBuild {
        debugCode()
    } else {
        releaseCode()
    }
}

forBuildStyle(
    debug: {
        print("I'm built for debuggin'!")
    },
    release: {
        print("I'm built for the wild!")
    }
)

Up to your personal preferences as to which API you adopt, and which implementation you choose (streamlined but private-Swift-bits-dependent with bonus unnecessary compiler warnings, or official-APIs-only but hacky).

let componentsOfPotentialInterest = [Calendar.Component: ((Int) -> String)](
 .day: { String($0 + 1) },
)

Push button.  Expect results (or at least bacon).  Get:

Foo.swift:76:21: error: expected ',' separator
 .day: { String($0 + 1) },
     ^
     ,
Foo.swift:76:21: error: expected expression in list of expressions
 .day: { String($0 + 1) },
     ^
Foo.swift:76:21: error: expected ',' separator
 .day: { String($0 + 1) },
     ^
     ,

Believe it or not, Swift, blindly repeating your obtuse error messages does not help.

What it’s trying but as usual failing miserably to tell me is that Dictionary doesn’t have an initialiser that takes key: value pairs (my mistake for writing straight-forward, Python-like code).  You have to use the dictionary literal syntax instead:

let componentsOfPotentialInterest: [Calendar.Component: ((Int) -> String)] = [
 .day: { String($0 + 1) },
]

Now it merely complains about the expression being too complex for its pathetic little brain, rather than having no fucking clue what you’re doing to begin with.  Pick your utterly useless poison, I suppose.

The fuck?

⤹ Me             Swift compiler ⤵︎

In today’s episode of “what the fuck do you want, compiler?”, we tackle:

foo.swift:186:39: error: ambiguous reference to member 'joined()'
       log.debug("\(thingies.joined(separator: ", "))")
                    ^~~~~~~~
Swift.BidirectionalCollection:27:17: note: found this candidate
 public func joined() -> FlattenBidirectionalCollection<Self>
             ^
Swift.Sequence:27:17: note: found this candidate
 public func joined() -> FlattenSequence<Self>
             ^
Swift.Sequence:18:17: note: found this candidate
 public func joined<Separator : Sequence where Separator.Iterator.Element == Iterator.Element.Iterator.Element>(separator: Separator) -> JoinedSequence<Self>
             ^
Swift.Sequence:16:17: note: found this candidate
 public func joined(separator: String = default) -> String
             ^
Swift.Collection:27:17: note: found this candidate
 public func joined() -> FlattenCollection<Self>
             ^

For context, ‘thingies’ is an array of a custom type.

What the compiler wishes it could say, if it weren’t incompetent, is that every one of Array‘s joined implementations are conditional.  The one that I want is is the second last one, but it is only defined for Array<String> specifically.  No other Array types.

Similarly every other one is conditional on the Element type within the Array being a specific type or protocol, none of which happen to apply to the types I’m using in my Array.

Now, my intuition is that since my type is CustomDebugStringConvertible, that Swift would know then how to convert my type to a String and then go from there.  For better or worse, however, it does not.  Instead you have to do it manually, e.g.:

log.debug("\(thingies.map({ String(describing: $0) }).joined(separator: ", "))")

And you can probably tell from that alone that I’m very used to Objective-C, where it’s very easy to write what you intend and get the results you intend.

The answer is pretty easy to find. The relevant code follows a similar path within Clang as the existing NSString literals, which is to say that the guts of it live in CGObjC.cpp. You’ll now find, in addition to the familiar EmitObjCStringLiteral():

• EmitObjCNumericLiteral()
• EmitObjCArrayLiteral()
• EmitObjCDictionaryLiteral()

What is unexpected is that they aren’t implemented the way you’d expect. Which is to say, the way NSString literals are implemented; as special, compile-time constructed instances that always exist. EmitObjCStringLiteral() ultimately just calls GetAddrOfConstantCFString() in CodeGenModule.cpp, which:

1. Checks that there’s not an existing string constant with the same value, in which case it returns the address of that.
2. Creates a global variable to be the NSString instance (actually an instance of whatever the constant string type is), and populates it with the class pointer, some flags indicating whether it’s UTF16 or not (in which case I presume it’s UTF8), the length, and a pointer to the actual string data…
3. Which is allocated as a separate global variable.

So you end up with your actual string plus a 16-byte NSString instance in the read-only data section of your library. Pretty efficient at runtime.

Yet the new literals aren’t implemented like this at all. Numeric literals could in fact be implemented even more efficiently – NSNumber supports tagged pointers, which is where the actual pointer contains the entire object, rather than pointing to a heap-allocated instance. It doesn’t work for all numbers, of course, but it handles a lot of common cases, and a fallback to a compile-time constructed instance would be fine.

Instead, it generates a runtime call to the appropriate class constructor method on NSNumber. So you’re going to hit e.g. +[NSNumber numberWithInt:] every single time you execute a line that contains @5. Don’t forget that means it gets added to the autorelease pool. While NSNumber does keep a cache of likely-common instances (small integers near zero, for example), that’s not tuned to your particular code and it’s not going to cover many uses.

That’s all amazingly inefficient. I can only assume that this is the naive initial implementation, that will then be improved upon.

Likewise the NSArray and NSDictionary literals are also emitted as runtime calls to the appropriate class constructor method (either +[NSArray arrayWithObjects:count:] or +[NSDictionary dictionaryWithObjects:forKeys:count:], by default).

For the collections at least I can see that being slightly more rational, given that the collections are significantly more complex than simple string or number literals, and those classes have been known to change their implementations at runtime depending on their capacity and other factors.

It’s also possible that it’s implemented this way, for now, in order to support all Objective-C runtimes, not just the Mac and iOS ones. This is in CGObjC.cpp after all, not CGObjCMac.cpp. Though it’s worth noting that string literals are handled differently between the Mac/iOS and the GNU runtimes.

I hope the implementation improves. Even performance aside, there’s some potential initialisation order problems that follow from invoking actual class methods to generate the literals. I don’t know if I’d shy away from using these new literals for the initialisation of static variables or constants, but I’d think twice about it.