Swift 2.1 Released
Posted on September 20, 2015
With the release of XCode 7.1, Swift 2.1 is now available.
It’s not a major release so don’t expect major changes to the language, here is a list of what changed:
-
Expressions interpolated in strings may now contain string literals. For example,
"My name is \(attributes["name"]!)"
is now a valid expression. Highly appreciated. -
Conversions between function types are supported, exhibiting covariance in function result types and contravariance in function parameter types (See the specific post on this: Swift 2.1 Function Types Conversion).
-
Enums imported from C now automatically conform to the
Equatable
protocol, including a default implementation of the == operator. This conformance allows you to use C enum pattern matching in switch statements with no additional code.
And some less evident changes:
-
The
NSNumberunsignedIntegerValue
property now has the typeUInt
instead ofInt
, as do other methods and properties that use theNSUInteger
type in Objective-C and whose names contain “unsigned..”. Most other uses ofNSUInteger
in system frameworks are imported asInt
as they were in Xcode 7. -
Field getters and setters are now created for named unions imported from C. In addition, an initializer with a named parameter for the field is provided.
For example, given the following Objective-C typdef:
typedef union IntOrFloat { int intField; float floatField; } IntOrFloat;
Importing this typedef into Swift generates the following interface:
struct IntOrFloat { var intField: Int { get set } init(intField: Int) var floatField: Float { get set } init(floatField: Float) }
-
Bitfield members of C structs are now imported into Swift.
-
The type
dispatch_block_t
now refers to the type@convention(block) () -> Void
, as it did in Swift 1.2.This change allows programs using
dispatch_block_create
to work as expected, solving an issue that surfaced in Xcode 7.0 with Swift 2.0. -
Editing a file does not trigger a recompile of files that depend upon it if the edits only modify declarations marked private.
-
Error messages produced when the type checker cannot solve its constraint system continue to improve in many cases.
For example, errors in the body of generic closures (for instance, the argument closure to map) are much more usefully diagnosed.
Did you like this article? Let me know on Twitter!