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 type UInt instead of Int, as do other methods and properties that use the NSUInteger type in Objective-C and whose names contain “unsigned..”. Most other uses of NSUInteger in system frameworks are imported as Int 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!

I'm also on Twitter and GitHub.

Subscribe via RSS or email.