Last week in Swift Evolution

Week of Dec 28, 2015

Published on

Happy New Year, everyone. Here’s a summary of selected updates from last week from the Swift Evolution repo and mailing list:

Up for review this week

  • New keyword for associate type declaration

    We declare associated types currently using the typealias keyword, and the same keyword is used to create an alias for a type. Loïc Lecrenier proposed a new keyword to declare associated types. The keyword was initially associated, and has now been changed to associatedtype.

    This proposal is up for review now (Jan 4 – Jan 6). This is quite a straightforward proposal (the main debate earlier was about what the new keyword should be named) and looks likely to be accepted.

  • Testing for Swift packages

    The Swift Package Manager team had proposed to include tests in Swift packages. The package manager looks for tests within a Tests subdirectory, and the tests can be run with a swift build --tests command.

    This proposal is scheduled for review this week (Jan 5 – Jan 7).

  • Flexible memberwise initialization

    Swift currently offers an automatic memberwise initializer for structs (unless they have an explicit initializer). Matthew Johnson proposed a way for this feature to be made available for classes (under certain conditions), and also allows us to specify values for private variables in the memberwise initializer (among other stuff). The proposed syntax looks like this:

    class MyClass {
    var i: Int
    private var j: Int
    memberwise init(...) { // '...' is part of the syntax
        j = 42
    }
}

let m = MyClass(i: 2)

    This proposal is scheduled for review this week (Jan 6 – Jan 10).

Discussions

These are the discussions from last week that I found the most interesting:

  1. Automatic protocol forwarding (last week)

    Per this draft proposal from Matthew Johnson, we can have function calls on a type (the forwarding type) automatically forwarded to a member (of type forwardee) of the forwarding type.

  2. Generalized naming for any function (previously here, last week)

    Swift functions can be assigned to variables, but when the same base name is shared by multiple functions (like insertSubview(view:UIView, aboveSubview: UIView) and insertSubview(view: UIView, belowSubview: UIView)), Swift doesn’t have a way for us to specifically name a particular function. Doug Gregor had proposed to name functions like this, and extended it to support setters, getters, initializers and subscripting.

    Last week, Joe Groff suggested that the same idea can be extended to disambiguate function calls (whether to call foo() in SuperProtocolA or in SuperProtocolB).

  3. Expression to retrieve the Objective-C selector of a method (earlier, last week)

    In a discussion related to the previous one, here’s a pitch to fix the “stringly typing” when we access Obj-C selectors in Swift. So, instead of the brittle btn.addTarget(self, action:"foo", ...), we can say something like: btn.addTarget(self, action:Selector(MyClass.foo), ...).

  4. Kevin Ballard suggested a bunch of additions to the Swift standard library:

Other