Swift 6 takes shape around ownership and concurrency

Swift has reached the point where distributing a library and changing a compiler can become separate decisions. That changes the context for the next major language version. Ted Kremenek's January 22 announcement puts ownership and concurrency at the center of the path toward Swift 6, without committing to a release date. The interesting engineering question is how to add more control while preserving the ordinary programming model that makes Swift approachable.

I find Swift consistently well designed, particularly where its types make local reasoning possible. The next stage deserves the same discipline. More explicit control over memory should help the programs that need it without making every application carry the complexity of a systems library. The existing ownership work gives that preference a fairly concrete technical basis.

Stability changes what can be distributed

The ABI explanation published in February 2019 separates runtime compatibility from the compiler's understanding of a module. A stable ABI lets an application built with one compiler interact with a library built with another. On Apple platforms, Swift 5 establishes that binary contract. It also permits the operating system to supply the Swift runtime and standard library, reducing what applications need to embed.

A compiler still needs an interface when it imports a framework. The older opaque swiftmodule representation depends on the compiler version, so runtime compatibility alone cannot make a binary framework convenient to distribute. Library evolution is another distinct concern. Replacing a library without recompiling its clients requires rules about which implementation details those clients can assume. Keeping these contracts separate explains why language maturity involves more than promising that source still compiles.

The Swift 5.1 release, published on September 20, supplies module stability through a textual interface describing a binary framework's API. That is the compile-time part of the distribution problem. The same release includes library evolution support. A framework author can now plan for clients whose compiler and update schedule differ from the framework's own.

Swift 5.1 also shows that stability does not stop language development. Property wrappers provide reusable property access behavior, and opaque result types let an API conceal a concrete implementation type. Those changes concern API expression, which remains a separate line of work in the January direction. The practical implication is that the project can improve library design during the 5.x series while larger ownership and concurrency questions remain open.

Ownership addresses costs hidden by values

John McCall's ownership manifesto, as present in the Swift 5.1 source release, explains the tension behind the proposed control. Copy-on-write collections make value semantics affordable, but reference counts and uniqueness checks still cost work. Predictability matters too. An occasional delay can make a computation unsuitable for real-time work even when its average execution cost is acceptable.

The manifesto proposes explicit ways to share values and to express values that cannot be implicitly copied. Such facilities would let an API communicate whether a call needs ownership or only temporary access. A compiler cannot always infer that distinction across an arbitrary function call. Additional information could remove copies that the implementation otherwise needs to preserve validity.

This is a proposal for selective control. Its stated success criterion allows ordinary programmers to ignore most ownership machinery. I like that constraint because value semantics are useful precisely when callers can understand mutation without reconstructing the implementation. A specialized optimization facility should preserve that advantage for code outside the specialized component.

Exclusivity is already part of the design

The Swift 5 exclusivity explanation documents one ownership-related rule already enforced in released tools. Modifying a variable requires exclusive access for the modification's duration. Passing storage as an inout argument therefore constrains other accesses while the call is active. Swift 5 extends runtime enforcement to Release builds, where Swift 4 had enabled those checks only in Debug builds.

That rule matters to optimization because an implementation can reason about a value while it has exclusive access. A callback that reaches back into the same storage would otherwise invalidate assumptions made during the modification. Some violations can be diagnosed statically, while others need a runtime check. The distinction concerns what the compiler can prove about access, not whether the program was built for debugging.

Ownership work consequently has a history inside the existing language. The future direction includes more control, but a major supporting restriction has already reached production compilation. Reading the January announcement against that history avoids treating ownership as a single feature waiting for one future release.

Packages can develop on a different schedule

Swift Numerics, announced in November 2019, provides a useful example of ecosystem work independent of a major language release. Its initial Real module supplies generic mathematical operations, while Complex supplies complex arithmetic. The accepted basic-math proposal could not yet enter the standard library in a source-stable way because of compiler limitations. A package makes the functionality available while that limitation remains.

The announcement's generic sigmoid example shows the intended programming model:

import Numerics

func sigmoid<T: Real>(_ x: T) -> T {
    1 / (1 + .exp(-x))
}

The generic constraint supplies the mathematical operation through the type's protocol conformance. Code can express the algorithm without fixing its input to one floating-point representation. Packaging also permits experimentation before an API becomes stable, and releases need not follow the compiler's calendar. Some numerical modules may eventually suit the standard library, while others have a useful home outside every application's default dependencies.

For library users, this separates two adoption decisions. A package can supply a domain API now, while language work continues on the facilities needed to express or implement such APIs better. That is a practical reason to care about the ecosystem alongside the language roadmap.

The next major version remains a development goal

January's direction includes faster builds and better diagnostics, with responsive completion and reliable debugging also receiving attention. Build times are the least pleasant part of writing small Swift apps for me. Treating development experience as continuing engineering work is therefore as relevant as adding expressive language features.

Concurrency still requires discussion and investigation. The announcement proposes using the working-group approach for that effort and describes Swift 5.2 as the active release under development. Further 5.x releases can make substantial progress before the project decides that the capabilities justify Swift 6. For anyone planning a library today, the available stability contracts and packages are concrete inputs. The future concurrency design remains work to participate in as its proposals become specific.