Apple provided new details about Swift 2.2 release process, its goals, and an estimated schedule. Swift 2.2 will be mostly a source-compatible release, while major, breaking changes will be left for Swift 3, Apple say.
The next release of Swift, the first after Apple open sourced the language, can be expected March to May of 2016, hopefully on time for Apple’s next World Wide Developers Conference (WWDC). It will mostly include bug fixes, enhancements to diagnostics and improvements to code generation, so it will not fundamentally change the way Swift is used, according to Apple. Furthermore, it will specifically not include the Swift Core Libraries, nor the Swift Package Manager.
On the other hand, more disruptive changes both to the language itself and its standard library are planned instead for Swift 3, which will be release in late 2016.
The key date in Swift 2.2 release process is January 13, 2016, when a swift-2.2-branch will be created from master for 5 repositories: swift, swift-llvm, swift-clang, swift-lldb, and swift-cmark. From that moment on, any bug fixes or enhancements will be considered only if they contribute to make the 2.2 release more source compatible with Swift 2.1 or if they add migration warnings that will become errors in Swift 3.
At the moment of this writing, when Apple is about to create the swift-2.2-branch, this is the list of new features that will go into Swift 2.2:
- Allow using most language keywords, such as
in,repeat, etc., as argument labels. - Tuple comparison operators, up to a certain arity
- Constraining AnySequence.init. to make it possible to delegate from
AnySequencetoSequenceTypeand spare some dynamic downcasts where that is required. - Add a Lazy flatMap for Sequences of Optionals to flatten a sequence of sequences after a transformation.
- Replace typealias keyword with associatedtype for associated type declarations, doing away with the conflation of using
typealiasboth for type aliases and associated types (placeholder name to type used as part of a protocol).
After the new branch is created, for a fix to be included in Swift 2.2, it must be first accepted in the master branch, then pulled in from there using a pull request, except in case of changes that are specific to Swift 2.2 and won’t be included in Swift 3. Pull requests will include an explanation, an assessement of the impact of the change, an avaluation of the associated risk, and details about tests that have been done or need to be done.