Last week in Swift Evolution

Week of Jan 25, 2016

Published on

Here’s a summary of selected updates from last week from the Swift Evolution repo and mailing list:

Under review this week

  • API Design guidelines

    Previously: Weeks of Jan 11, Jan 18.

    Given that the API redesign is one of the most important changes coming to Swift in 3.0, Apple wrote about this effort in the Swift blog.

    The API Design Guidelines is the umbrella proposal. The changes proposed in the other two proposals are motivated by these API design guidelines. The guidelines themselves are here: proposed version, in-development version.

    Discussion on the guidelines included these points:

    • On the guideline that says:

      When a mutating method is described by a verb, name its non-mutating counterpart according to the “ed/ing” rule, e.g. the non-mutating versions of x.sort() and x.append(y) are x.sorted() and x.appending(y).

      • Chris Lattner seconded the InPlace suffix to name mutating methods (like sortInPlace(), reverseInPlace())
      • Erica Sadun shared her thoughts in a Github document.

    • As per the guidelines, redundant type names should be removed from function names (like removeElement() becomes remove()).

      So, how would we want the API to look at the call site for inserting into an list of items? These are the possibile options:

      1. items.insert(12, atIndex: 2) (current API)
      2. items.insert(12, at: 2)
      3. items.insert(12, index: 2)

      Radosław Pietruszewski prefers (3), because it conveys more meaning, even if (2) reads more like English. He says:

      I think there’s an agreement that making Swift sound like English is a non-goal. In fact, trying to do so is often harmful as we end up putting unnecessary words, like “with”, “and”, “by”, etc. (I’m not saying they’re always unnecessary; they often help convey the semantics or intent, or are needed for the method name to make sense. But too often they’re just glue words used to make code sound like English without any actual readability benefits, and merely adding noise.)

    • Chris Lattner supported the idea of changing enums so that the enum cases are defined with lowerCamelCase names.

    • The guidelines doesn’t currently talk about how initialisms (like HTML, UTF) should be handled in the API. The predominant opinion is that they should either be all-uppercase (like in function names e.g. HTMLoutput()), or all-lowercase (like in variable names e.g. let htmlString = "<u>\(string)</u>")

    The deadline for this review has been extended to Feb 5, 2016.

  • Modernizing __LINE__, etc.

    While discussing how Obj-C selectors can be referenced cleanly from Swift (previously: Weeks of Jan 11, Jan 18), Chris Lattner suggested that “we could consider renaming __LINE__ and friends to #LINE”.

    Erica Sadun has developed that small suggestion into a full-fledged proposal to rename __LINE__ to #line, __FILE__ to #file, __COLUMN__ to #column and __DSO_HANDLE__ to #dso_handle.

    The review of this proposal runs till tomorrow (Feb 2, 2016).

Accepted proposals

Other stuff

  • Chris Lattner commented on what Swift 3.0 is “really about”:

    Overall, this comes back to a higher order philosophy about what Swift 3 is really about: it is about driving the next wave of adoption of Swift by even more people. This will hopefully come from new audiences coming on-board as Corelibs + Swift on Linux (and other platforms) become real, SwiftPM being great and growing into its own, and the Swift language/stdlib maturing even more.

    In the same mail, he also talked about the goal of stabilizing the syntax in Swift 3.0:

    While our community has generally been very kind and understanding about Swift evolving under their feet, we cannot keep doing this for long. While I don’t think we’ll want to guarantee 100% source compatibility from Swift 3 to Swift 4, I’m hopeful that it will be much simpler than the upgrade to Swift 2 was or Swift 3 will be.

Other weeklies