Swift project in 2023

November 18, 2022

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:

• Language Workgroup — evolving the language and standard library
• Website Workgroup — managing web content on swift.org
• Documentation Workgroup — organizing development of documentation tools and libraries
• C++ Interoperability Workgroup — incubating language proposals for improving interoperability with C++

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:

• Allow build systems to integrate more deeply with the Swift compiler, giving them more flexibility on how they build Swift programs and make builds more robust. This work includes moving the Swift compiler toward explicit module loading, and separating the discovery and compilation of module dependencies into separate compiler invocations. It also includes adding the ability to discover a module’s link-time dependencies, permitting the build system to directly invoke the linker itself instead of requiring it to be invoked through the Swift compiler.

• Enhance the quality of automatically generated Swift textual interfaces and the binary module infrastructure to help library authors ship their Swift APIs more reliably and efficiently. Related diagnostics will also be added to nurture good engineering practices.

• Develop features to enable flexible software integration, allowing software components developed by different teams at different cadence to be integrated smoothly, both at compile-time and at run-time.

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 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:

• Develop a Swift parser that’s written in pure Swift and feature-complete with the current C++ implementation. This opens up new directions in tooling development and will eventually replace the C++ parser.

• Improve the type checking performance of result builders by migrating the type inference implementation to a more scalable infrastructure that supports multi-statement closure inference.

• Improve the reliability of code completion and lookup-dependent tools such as Quick Help and Jump to Definition, especially in incomplete or ambiguous code, by integrating more closely with the type checker.

• Generate less code when converting functions by removing the need for conversion thunks in some cases, particularly when passing closures to generic and imported functions.

• Generate less code when copying and destroying complex structs and enums by interpreting a compact encoding of the type layout instead of emitting specialized functions.

• Add SIL optimizer support for new language features and predictable optimization related to object lifetimes and copies. A new suite of low-level SIL utilities are being designed to maintain ownership invariants throughout the existing optimization pipeline. This will result in reliable diagnostics and predictable performance.

• Rewrite the current interprocedural side-effect and escape analyses in Swift, replacing the current C++ implementations. The new implementations provide more accurate results and are significantly simpler.

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:

• Improve the content on the website’s most visited pages, including the home page, the Getting Started guide, and the Download page. It is important these pages are intuitive to use and include just the right information to achieve that goal. The workgroup also wants to improve the discoverability of documentation, another area visitors of the website often seek.

• Iterate on layout design and navigation. The workgroup plans to roll out the foundation of a visual design system that can help the community contribute in domain-specific areas such as the Swift on Server guides.

• Encourage the participation of the broader Swift community in the evolution of swift.org, making it easier to contribute to the website and Swift documentation.

• Encourage the publishing of community-driven blog posts, streamlining the process and clarifying the guidelines for such posts.

• Continue to explore Swift-based technologies for generating the website.

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:

• Drive full adoption of the Swift concurrency model across the server ecosystem, adopting async/await APIs as the standard for user-facing APIs.

• Promote standardization of higher level server side functionality, including tracing, middleware, HTTP common types, and basic routing/HTTP server types.

• Increase awareness of how SwiftPM plugins can be used to advance the state of tooling for server use cases, including deployment to cloud platforms.

• Increase the coverage and consistency of the toolchain, libraries, and tooling across all platforms officially supported by the Swift project.

• Expand the server focused guides available on swift.org.

• Advance the support of Swift in popular industry tools such as Dependabot, GitHub Security Advisory DB, and others.

Differentiable Swift

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

• Improve robustness by fixing issues in differentiable Swift that impact production applications as they are encountered. Fewer and fewer of these issues are being observed over time, but there are still some known issues (many with simple reproducers) in the issue tracker.

• Significantly improve the performance of compiled code using Differentiable Swift. One example concerns the compiler-generated “backwards pass” through a Swift function. In principle, executing this pass should be nearly as fast as the original (“forward”) version of the function. At present, the backwards pass is orders of magnitude slower in many cases; there are some planned optimizations over the next year that should make the backwards pass much faster.

• Implement performance improvements to KeyPaths. While not strictly part of Differentiable Swift, key paths become extremely important when optimizing strongly-typed models for introspection. As a first step, there is an effort to add a robust set of key path benchmarks to the compiler suite.

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.

Swift 5.7 Released!