Week of Jan 25, 2016
Under review this week
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
- Chris Lattner seconded the
InPlacesuffix to name mutating methods (like
- Erica Sadun shared her thoughts in a Github document.
- Chris Lattner seconded the
As per the guidelines, redundant type names should be removed from function names (like
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:
items.insert(12, atIndex: 2)(current API)
items.insert(12, at: 2)
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.
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
Erica Sadun has developed that small suggestion into a full-fledged proposal to rename
The review of this proposal runs till tomorrow (Feb 2, 2016).
This proposal was accepted for Swift 2.2 with the syntax changed to
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.
- Jesse Squires’ Swift Weekly Brief Issue #7 covers the week till last Thursday