Chris Lattner on Swift 3 and Cocoa "Renamification"

In a recent post on the swift-evolution mailing list, Swift creator Chris Lattner outlined a few criteria that will guide Swift 3 definition and made clear that it will bring disruptive changes.

While acknowledging that it is not easy to predict what will end up in Swift 3, due to the multiple unknowns that are intrinsic in designing and implementing new features, Lattner highlights a main goal and a few means that will make it possible:

Swift 3 […] 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 [Swift Package Manager] being great and growing into its own, and the Swift language/stdlib maturing even more.

With Swift 3’s scope being so clearly defined, Lattner adds that many “good ideas” will be set aside, especially when they imply large extensions to the language that do not affect the core model:

I think that we’ve had a consistent approach with Swift 3, where we’re focused on fixing core deficiencies in the base language, fixing implementation issues and designing resilience features that affect ABI stability, while taking on small scope extensions to the language.

An example of a feature that might not make it into Swift 3 is flexible memberwise initialization, while an example of a feature that is highly desired in Swift 3 is property behaviours, which would help cleaning up some compiler magic related to the implementation of lazy, @NSManaged, etc.

Yet, Swift 3 is going to bring a massive, breaking change, mostly due to renaming of Cocoa methods to make them more “Swift-like”:

Swift 2 to Swift 3 is going to be an unavoidably disruptive change for code since Cocoa renamification is going to land, and we’re going to be building impressive migration technology again.

The renaming of Cocoa methods would imply several changes, such as:

• Streamlining method names by removing unnecessary words specifying the type of the expected argument, e.g.:

  let content = listItemView.text.stringByTrimmingCharactersInSet(NSCharacterSet.whitespaceAndNewlineCharacterSet())

  would become:

  let content = listItemView.text.trimming(.whitespaceAndNewlines)

• Removing the NS prefix from Foundation APIs, e.g., var NSDateComponentUndefined: Int { get } would become var dateComponentUndefined: Int { get }

• Adding default arguments to method declarations, such as nil for nullable trailing closure parameters, [] and [:] for arrays and dictionaries whose name read options, attributes, info etc.

Lattner’s statement that Swift 3 is going to be non source compatible gave rise to a few complaints. Lattner himself said he is aware that they cannot go on and make Swift change under “developers feet” for long, but he hopes that the transition from Swift 3 to 4 will be much simpler. Still, Apple plans on providing a migration switch (-swift3-migration) that will make developers life easier when porting Swift 2.2 code to Swift 3.