Swift Language focus areas heading into 2025

Evolution Announcements
1

With Swift 6.0 and the Swift 6 language mode now released, Swift language development under the Language Steering Group is now focused on three major areas:

  • making Swift Concurrency easier to approach and adopt,
  • providing powerful low-level language and library tools for high-performance programming and constrained environments, and
  • improving language interoperability, especially with C++ and Java.

The Swift 6 language mode provides a strong base for Swift Concurrency, but many developers are finding it difficult to adopt. The LSG is considering several ideas which we believe may significantly ease that burden. We’ve written about this at length in the prospective vision for approachable concurrency, and we're now looking for feedback on those ideas; please check it out.

Simultaneously, the LSG is interested in improving Swift’s facilities for avoiding copies and working safely with restricted values. Implementors are currently working on Span types that can be used to safely read and write contiguous arrays of objects in memory without needing to manage the memory itself. Making this memory-safe requires the use of better language support for non-copyable and non-escaping types. We are also working on features that will allow programmers to “borrow” values (read from them without copying their representation) in more situations. Taken together, this work will both make it easier to optimize the performance of Swift code and allow Swift to be safely adopted in more constrained environments, such as those envisaged by the Embedded Swift effort.

Those same language facilities are also critical for safe interoperation with C++. C++ libraries often rely on unsafe assumptions for correct usage; for example, it is common for C++ functions to return references derived from references they received as arguments, and it just has to be understood by the programmer that the return value cannot be safely used once the argument has become invalid. Swift’s support for non-copyable and non-escaping types will allow the compiler to reason about these functions and ensure that they’re used correctly, making it possible to use C++ from Swift with far greater confidence and much cleaner code.

Finally, there is an exciting new project to allow Swift to directly interoperate with Java. Historically, Swift has pursued interoperation with the C family of languages using deep integration with the Clang compiler. For Java interop, however, we are pursuing a more library-oriented solution based around reading and writing Swift interfaces. Ultimately, we hope that this project will not just allow Swift to fit cleanly into the JVM, but also enable much simpler interoperation for a broad spectrum of other languages.

We don't mean to imply that anything not on this list will not be considered; this is just a brief overview of the areas we're currently most focused on.

John McCall
Language Steering Group

61 Likes
2

The biggest difficulty I face today is the lack of unified, coherent documentation, with lots of examples showing how to solve real world problems. I also find the lack of direct support for communicating sequential processes quite disappointing.

However, I remain optimistic that the status quo will start to change for the better in the near future.

11 Likes
3

Since low-level performance is a focus area, can I ask if that includes fully enabling Ownership SSA?

When inspecting the performance of my code, I've sometimes been surprised that the optimiser wouldn't eliminate certain copies (manifesting as retain/release pairs). For example, just iterating an array:

func iterate(_ arr: Array<Int>) {
  for i in arr {
    blackhole(i)
  }
}

// building with -O:

call    swift_retain@PLT
;...
call    blackhole@PLT
;...
jmp     swift_release@PLT

These go away when compiling with -Xfrontend -enable-ossa-modules.

As @Michael_Gottesman described in his LLVM talk, Ownership SSA is a new lowering which preserves ownership information and is better at eliminating unnecessary copies, and my understanding is that for non-stdlib libraries, it currently gets stripped partway through the optimiser because it is not ready for general use.

Can we expect this to be enabled by default in the coming year?

Even as we add more manual control over copies (or even especially as we do), I think it's also important that we raise the bar for which copies developers can reasonably expect the optimiser to eliminate on its own by making these improvements more widely available. I know the optimiser folks have been working very hard on it for a long time.

11 Likes
4

The -Xfrontend -enable-ossa-modules mode that you mentioned is indeed a focus this year. That makes it possible to optimize copies across module boundaries--as needed in your Array example. There is a lot more work to fully take advantage of OSSA, but this is an important step.

11 Likes