The Roadmap to Swift 4

Expected to be released in late 2017, Swift 4 will aim to stabilize the language, both at the source code and ABI level. New features will include improvements to generics, and a Rust/Cyclone-inspired memory ownership model.

Swift 4 development will be divided in two stages. The first stage will include all features that are required to stabilize Swift ABI while also ensuring source compatibility with Swift 3. The second stage, which is still somewhat undefined, may also contain new language features, both large and small, provided they do not change the ABI of existing language features or break the ABI to the standard library.

Source compatibility

The requirement of source compatibility is a fundamental one, although having a stable language might impair the language ability to evolve. To enable rapid progress for the language while ensuring source compatibility, the Swift team will extend the existing @available attribute to make it indicate the availability of a feature not only relative to a particular platform or OS version, but also relative to Swift language versions.

For example, this is how you could declare an API that is obsoleted in Swift 3.1:

@available(swift, obsoleted: 3.1)
class Foo {
  //...
}

ABI stability

Stabilizing the Swift ABI will require on the one hand laying out the foundations for new features to be added, a feature known as resiliency, which will provide a way for public APIs to evolve while guaranteeing ABI stability. This can be accomplished, e.g., by making it explicit what parts of the APIs can change without breaking the ABI, thus eliminating the fragile base class problem that occur in some object-oriented languages.

On the other hand, stabilizing the ABI requires cleaning up existing deficiencies in the language so they do not become a permanent part of the ABI. In particular, a number of such improvements have been already identified, such as:

• conditional conformances, which express the notion that a generic type will conform to a particular protocol only when its type arguments meet certain requirements. An example of this is the Array collection, which can implement the Equatable protocol only if its elements are Equatable:

  extension Array: Equatable where Element: Equatable {
    static func ==(lhs: Array<Element>, rhs: Array<Element>) -> Bool { ... }
  }
  

• recursive protocol requirements, which makes it possible for an associated type to conform to an enclosing protocol. For example, a Subsequence should be itself of Sequence, hence Swift 4 will allow the following, currently ill-formed, definition:

  protocol Sequence {
    associatedtype Iterator : IteratorProtocol
    ...
    associatedtype SubSequence : Sequence   // currently ill-formed, but should be possible
  }
  

• where clauses for associated types, which will bring the expressive power of where, already available with generic type parameters, to associated types. E.g.:

  protocol Sequence {
    associatedtype Iterator : IteratorProtocol
    associatedtype SubSequence : Sequence where SubSequence.Iterator.Element == Iterator.Element
    ...
  }
  

Finally, a big chunk of work will go into defining an opt-in memory ownership model inspired by Cyclone’s and Rust’s. Rust memory management is based on the concept of ownership of an entity, which can be moved or borrowed to keep track of who is responsible for deallocating it and who can use it. This is coupled with a notion of lifetime to avoid dangling references when an entity is finally deallocated. C-dialect Cyclone, which is not currently under development anymore, used a region-based memory management model, where each allocated entity is assigned to a region to increase allocation/deallocation performance and to better support the detection of deallocated entities. Extending Swift memory management model will be particularly useful to system programmers and in all cases where deterministic performance is a highly desirable. This effort will foreseeably extend beyond the limits of stage 1, for which the goal is to have a comprehensive design to understand how it will change the ABI.