Swift Language Version Build Configuration
You can now test for Swift version in code.
For example:
#if swift(>=2.2) print(“Hello!”) #else if swift(1.0) println(“Hello!”) #else This code will not parse or emit diagnostics #endif
There’s a great (and active) discussion going on about other potentially supported conditions. Evan Maloney proposes:
- Is the target an Apple platform (iOS, OS X, tvOS, watchOS) or not? (Answers the question “can I import Foundation”?)
- Is the target a “common UIKit platform” (compiles on both iOS and tvOS) or not? (Answers the question “can I import UIKit”?)
- Is the target a specific platform (iOS, OS X, tvOS, watchOS, Linux, etc.)?
- Is the target in Debug or Release mode?
- Is the target a simulator environment or a physical device?
- Is the target built for running tests?
Other recommended tests include “Is this a Darwin target?”, “Does this target support importing UIKit (iOS, tvOS) or Cocoa?”, etc.
Referencing the Objective-C Selector of a Method
You now construct a Swift method’s Objective-C selector using #selector
:
let sel = #selector(insertSubview(_:aboveSubview:)) // sel has type Selector
String literal selectors are now deprecated:
let sel: Selector = "insertSubview:aboveSubview:" // nope
The compiler will recommend fixits where possible, otherwise you’ll need to use a Selector initializer:
let sel = Selector("propertyName")
The compiler now checks that “the string literals used to construct Selectors to ensure that they are well-formed Objective-C selectors and that there is an @objc method with that selector.”
Replacing typealias
with associatedtype
Swift 2.2 deprecates using the typealias
keyword for associated types (which is being renamed) and Swift 3 will eliminate its support for this usage. From now on, use associatedtype
, which describes a type associated with a generic item, for example, the elements and indices of a collection, or the streams combined together for a zipped sequence. You can continue using typealias
for making type aliases indefinitely.
Naming Functions with Argument Labels
Since Swift enables you to overload functions, just using names can reference more than one function. Adding argument labels to function names provides disambiguation for a modern language.
let fn1 = someView.insertSubview(_:at:) let fn2 = someView.insertSubview(_:aboveSubview:) let buttonFactory = UIButton.init(type:)
Eliminating Ophidiophobia
Swift 2.2 refactors screaming snake case identifiers to pleasant #-delimited expressions.
New #file, #line, #column, and #function expressions have been introduced to replace the existing __FILE__, __LINE__, __COLUMN__, and __FUNCTION__ symbols. The __FILE__-style symbols have been deprecated, and will be removed in Swift 3.
I have a particular fondness for this improvement, which enhances the way you can recover context when doing any kind of logging and debugging.
5 Comments
Erica, concerning your iBooks, are they being kept up-to-date with the latest Swiftolgies? Specifically, I’m thinking about the Playgrounds book (last updated, April 2015), but also interested in the Documentation Markup book too. Thanks.
Yes, I update frequently. I’m going to take a wild guess that you bought from Amazon? https://ericasadun.com/2015/04/06/swift-playground-secrets-and-power-tips-available-on-ibooks/
Just tested the code snippet about build configuration, it looks like a unary comparison is required. So, line 3 should be #elseif swift(>=1.0), otherwise you will get a compiler error.
How does a syntactic change the enhance (or have any effect) on context recovery?
https://ericasadun.com/2015/08/27/capturing-context-swiftlang/