Swift project in 2023

John McCall John McCall

There’s a lot of exciting work going on in the Swift project, and it’s hard to keep track of it all because it’s happening in many different repositories, pull requests, and forum threads. To give the community a better view of the big picture, the Core Team surveyed workgroups and developers across the project and collected information about what they’re focused on over the next year.

Please keep in mind that nothing here is a lock for any particular release of the project — plans and priorities can change over time. This also isn’t an exhaustive list of everything happening in the project. But we hope you find this interesting and informative, and if you have questions about any of these areas, please feel free to reach out and ask for more details.

Community Organization

For a long time, Swift has had a fairly centralized structure, with the Core Team directly overseeing many different areas of the project.

The Core Team has recently begun reorganizing so that more responsibility is held by dedicated workgroups:

These new workgroups join the longstanding Swift on Server and Diversity workgroups, and make it easier for people to contribute by joining a workgroup dedicated to their interests.

The Core Team is investigating creating several more workgroups, including one dedicated to improving Swift’s usability across platforms.

Core Team Update

Mishal Shah will be joining the Core Team. As a lead and advocate for much of the underlying infrastructure that supports the Swift project, Mishal has played an essential role in supporting the Swift project’s growth for some time.

Language Development

The Language Workgroup is focused on making progress in five major language areas:

  1. Concurrency. Complete the language support for the strict data isolation provided by Sendable and actors. This includes closing a number of known thread-safety holes, such as those around global variables and certain cross-actor calls. It also includes the possibility of adding language features to solve some usability problems that come with strict isolation, like allowing non-Sendable values to be moved between isolation domains in restricted situations.

  2. Generics. Start work in earnest on the variadic generics language feature. This is a major feature that is expected to take multiple years to complete. The initial focus is on designing the core language model and implementing the basic compiler and runtime infrastructure to support it. One early milestone will be to allow tuple types to conditionally conform to protocols like Equatable when their elements do.

  3. Ownership.

    • Develop features to give programmers explicit control over the ownership of values in memory. This includes features to prohibit implicit copies, transfer ownership between contexts, and explicitly “borrow” values without copying them.

    • Add basic support for non-copyable types. This will provide new ways to achieve high performance by restricting the lifecycle of critical values. These controls will enable new ways to work with data in memory, combining the performance of current “unsafe” constructs with the safety of Swift’s standard library features.

  4. Macros. Develop the basics of procedural macros to further empower the creation of rich libraries and DSLs. This effort will start with the creation of a vision document to lay out a design for what macros can achieve in Swift and how they might fit into the language.

  5. C++ interoperability.

    • Write documents laying out the design visions for how C++ APIs will be made usable from Swift and vice-versa.

    • Stabilize the currently prototyped interoperability features for using C++ from Swift, which include owned value types, trivial value types, API patterns such as foreign reference types and iterators, and some of the fundamental questions around methods, pointers, and l-value and r-value references.

    • Stabilize the currently prototyped interoperability features for using Swift from C++, including how Swift value types, reference types, and functions are exposed to C++.

Any language changes arising from this work will be pitched and reviewed as normal under the Swift evolution process.

The Language Workgroup is also focused on improving and clarifying the evolution process, and will publish detailed documentation of the process used when managing a proposal as well as guidelines for proposal authors and reviewers.

Finally, the Language Workgroup is planning to finalize expected language changes for the upcoming Swift 6 language mode. Swift periodically introduces new language modes so the language can progress without breaking source compatibility for existing code.

Build System Integration and Improvements

Compiler development teams are working on improving how the compiler interacts with the build system and other invocations of itself:

Package Registry

Development on the Swift package manager is focused on starting work on an open source package registry server implementation in concert with the community. The goal is to create the technical components required to transition the Swift package ecosystem from one based on source control to one based on registries, enhancing the security and reliability of the ecosystem. We will work with community-run projects such as the Swift Package Index to ensure great package discovery alongside the benefits that the registry brings.

Implementation Improvements

Compiler developers are focused on several improvements at the implementation level:

Documentation Workgroup

The newly-formed Documentation Workgroup is excited to drive efforts toward a better documentation experience across the Swift ecosystem. Over the next year, the workgroup will evolve tooling to address documentation needs and guide new efforts to contribute to the Swift project’s documentation.

To encourage more and better documentation in the Swift ecosystem, the workgroup’s initiatives will be two-fold:

  1. Simplify the process to get started writing and publishing documentation using Swift-DocC. One goal is to enable developers to generate documentation without configuring an additional plugin.

  2. Expand the scope of Swift-DocC to support multi-target project configurations and long-form prose content. For packages that are composed of multiple libraries, support publishing documentation for the package as a whole rather than each of its individual libraries.

The workgroup will also support the development of the newly open-sourced “The Swift Programming Language” book, with a goal of replacing the existing publication pipeline with the contents of the new repository. This work will include defining guidelines for writing great documentation for the Swift language, with the longer-term goal of defining documentation guidelines for the Swift ecosystem at large, similar to the API naming guidelines.

Website Workgroup

The newly-formed website workgroup is focused on enhancing the swift.org website in a number of ways:

Swift on Server Workgroup

The Swift on Server Workgroup continues to focus on advancing the state of Swift on the server and on Linux, working with the community to create high-quality libraries and tools, and increasing awareness in the industry. The workgroup is focused on a few areas:

Differentiable Swift

Work continues on supporting AI/ML applications with Differentiable Swift, focused on a number of improvements:

Getting Involved

If you’re interested in getting involved, there are a lot of ways to do it.

Language changes go through the evolution process, so keep an eye out for discussion threads, pitches, and proposal reviews about the work that you’re interested in.

If you have questions or feedback about any of the items in this post, reach out to the appropriate workgroup or ask on the forums thread associated with this post.