Last week in Swift Evolution

Week of Dec 21, 2015

Published on , last modified on

A summary of selected updates from last week from the Swift Evolution repo and mailing list:

Upcoming reviews

  • 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’s proposal to use associated to declare associated types will be coming up for review next week.

  • The idea of having flexible memberwise initialization was selected for review last week.

    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 likely to be up for review next week.

Accepted proposals

  • Currently, flatMap works lazily only for sequences of non-optionals. Oisin Kidney’s proposal to make flatMap work lazily for sequences of optionals as well was accepted for inclusion in Swift 2.2.

  • The proposal for tuple comparison operators was accepted for inclusion in Swift 2.2, and merged into the Swift codebase.

    At present, comparing tuples requires the relevant equality or comparison operations to be written explicitly. Kevin Ballard proposed that the Swift standard library should include equality (==, !=) and comparison (<, <=, >, >=) operators for 2-tuples, 3-tuples, 4-tuples, 5-tuples and 6-tuples. This is implemented through a gyb file: Tuple.swift.gyb.

  • The implementation for the previously accepted proposal for allowing language keywords as argument labels was merged into the Swift codebase.

    To use a Swift keyword (like in, for example) as an argument label in a Swift function, we currently have to escape it in backticks (like indexOf(value, `in`: collection) – because in is a keyword). The backtick-escaping won’t be necessary in Swift 2.2.

Discussions

A few discussions that caught my eye last week:

  1. Replace ‘inout’ with ‘&’ (earlier, last week)

    The use of inout in function declarations looks very similar to argument labels, especially now that keywords will be allowed as labels. For example, func foo(inout x: Int) looks very similar to func foo(label x: Int). Joe Groff proposed that we could use & instead to make it easier to perceive the difference when reading code (one way to do that would be func foo(&label x: Int)). Erica Sadun proposed a few other syntaxes, the most popular of which seems to be func foo(x: inout Int).

  2. Final by default for classes and methods (earlier, last week)

    Swift classes are at present non-final unless marked as final. There’s a discussion on making them final by default, or atleast “sealing the classes” by default across module boundaries, and requiring that classes and / or methods that can be overridden be marked explicitly in code (with something like inheritable / overridable).

    The motivation to have all classes final by default is to make inheritability of classes explicit, so that we’re forced to think about that aspect when designing the class. The motivation for “sealed by default” is to enable not having to think about inheritability while working on one’s own codebase, but forcing us to think about it when having to ship a framework, so that API contracts can be kept in future versions of the framework. There will also be performance benefits with both ideas because the compiler can optimize finalized method calls better.

    The arguments against the “final by default” idea included:

    • It’s annoying to have to annotate every class / method in order to inherit / override it
    • It might make it harder for beginners to learn Swift
    • We can’t use testing methods that relied on overriding

    The arguments against the “sealed by default” idea included:

    • We’ve had to monkey-patch Apple frameworks to workaround bugs or other behaviours, which might be affected by this change. (Personally, I think this point is valid but not relevant).

      Michael Tsai has a good roundup of this argument from the mailing list, twitter and blog posts.

  3. Generalized naming for any function (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 has a proposal to name functions like this, and extends it to support setters, getters, initializers and subscripting. The syntax for this is still being debated.

Update (Dec 30): You might also want to take a look at Erica Sadun’s roundup of last week’s Swift Evolution discussions.