The last two weeks have been very active. Swift core team shared an article explaining Swift concurrency roadmap and multiple other great resources. I think it will be very exciting to see what is going to happen in near future.

There are awesome news from Swift on the Windows development side. The initial port of the Swift system has merged. It’s great to see Swift reaching new horizons and getting one step closer to total world domination. It is a famous quote by Chris Lattner.

Podcasts

John Sundell and Vincent Pradeilles talk about Key paths, functions and closures.

In the latest episode of Swift Unwrapped, Jesse and JP talk about Swift Atomics.

News and community

Max Desiatov tweeted that http://swift.org website is not searchable, contains outdated information, and is not translated to any other language. He purposed that it should be open-source. You can head down to the issue and vote there.

Commits and pull requests

Ben Barham merged a pull request that fixes missing declarations in the completions list due to their type being invalid.

Josh Learn created a pull request that resolves SR-13639: Don’t diagnose local type declarations as unreachable.

Alejandro Alonso merged a pull request that implements Equatable, Comparable, and Hashable conformance for tuples.

Michael Ilseman merged a pull request that adds enough shims and tweaks the types sufficiently to allow building System on Windows.

Accepted proposals

SE-0289: Result builders was accepted.

This proposal describes result builders, a new feature which allows certain functions (specially-annotated, often via context) to implicitly build up a result value from a sequence of components.

In effect, this proposal allows the creation of a new class of embedded domain-specific languages in Swift by applying builder transformations to the statements of a function. The power of these builder transformations is intentionally limited so that the result preserves the dynamic semantics of the original code: the original statements of the function are still executed as normal, it’s just that values which would be ignored under normal semantics are in fact collected into the result. The use of an ad hoc protocol for the builder transformation leaves room for a wide variety of future extension, whether to support new kinds of statements or to customize the details of the transformation. A similar builder pattern was used successfully for string interpolation in SE-0228.

Result builders have been a “hidden” feature since Swift 5.1, under the name “function builder”, and the implementation (and its capabilities) have evolved since then. They are used most famously by SwiftUI to declaratively describe user interfaces, but others have also experimented with building Swift syntax trees, testing, a Shortcuts DSL, a CSS DSL, and an alternative SwiftPM manifest format. There’s a GitHub repository dedicated to awesome function builders with more applications.

Proposals in review

SSWG-0016: Soto for AWS is under a review.

Amazon Web Services (AWS) is the largest provider of cloud services. Many companies rely on the systems and automation they provide. These include storage, security, identity, messaging, databases, compute, machine learning and analytics to mention a few.

AWS provides SDKs to interact with their services using the languages Javascript, Go, Python, C#, PHP, C++, Java, Ruby but don’t provide a first-party, fully comprehensive SDK in Swift.

Soto provides a Swift NIO based interface to access all Amazon Web Services.

Swift Forums

Swift Concurrency Roadmap

Ben Cohen posted the roadmap about structured concurrency in Swift.

The end state of these changes will:

• make asynchronous programming convenient and clear at the point of use,
• provide a standard set of language tools and techniques that Swift developers can follow,
• improve the performance of asynchronous code through better knowledge at compile time, and
• eliminate data races and deadlocks in the same way Swift eliminates memory unsafety.

Doug Gregor and John McCall explained about Actors & actor isolation.

The actor model involves entities called actors. Each actor can perform local computation based on its own state, send messages to other actors, and act on messages received from other actors. Actors run independently, and cannot access the state of other actors, making it a powerful abstraction for managing concurrency in language applications. The actor model has been implemented in a number of programming languages, such as Erlang and Pony, as well as various libraries like Akka (on the JVM) and Orleans (on the .NET CLR).

Doug Gregor explained how existing APIs from Objective-C would look like.

Swift’s concurrency feature involves asynchronous functions and actors. While Objective-C does not have corresponding language features, asynchronous APIs are common in Objective-C, expressed manually through the use of completion handlers. This proposal provides bridging between Swift’s concurrency features (e.g., async functions) and the convention-based expression of asynchronous functions in Objective-C. It is intended to allow the wealth of existing asynchronous Objective-C APIs to be immediately usable with Swift’s concurrency model.

John McCall described how async functions which can run on lightweight tasks will look like.

Our approach borrows heavily from the well-received async / await features in many other languages. I’ve included a portion of the proposal below; the full text can be found here. This feature ties in closely with the proposals for structured concurrency and actors.

John McCall skeched out how do async tasks interact with each other. It is inspired by Trio and Kotlin.

Any concurrency design has to provide some way of actually running code concurrently. We propose embracing the approach of structured concurrency, in which concurrent programs are organized into tasks and child tasks rather than simply a sea of formally-unrelated threads and jobs. Structured concurrency allows us to neatly address a large number of systemic problems with task management that would otherwise need a lot of ad hoc support.

Other topics

Chris Lattner shared a document about protocol-based actor isolation.

I got a chance to write up some thoughts on how to address one of the major challenges with the recent actor model proposal: how do we ensure that values transferred between actors do not introduce shared mutable state.

Dave Abrahams opened a thread about ValueSemantic protocol.

Max Ovtsin pitched a proposal about opt-in reflection metadata.

Reflection can be a useful thing to create convenient and concise APIs for libraries. This proposal seeks to improve the safety of such APIs and to tackle the binary size problem by introducing a mechanism of selectively keeping reflection metadata only for types that need it and dead strip it for all others. Developers will gain an opportunity to express a requirement to have reflection metadata in source-code.

Kirill Titov started a thread about the future of Swift-NIO in light of Concurrency Roadmap.

So what does it mean for us? Rest in peace EventLoopFutures? I realise that it’s just a roadmap and a series of pitches, and things might (will) change a lot, but it’s certainly the future, and it’s unlikely that Swift-NIO would want to ignore it.

Max Desiatov pitched a proposal that would support specifying Wasm features in package manifests.

As a quick introduction, I need to mention that WebAssembly is a collection of multiple proposals that are at different implementation stages in WebAssembly hosts. The bare minimum is called WebAssembly MVP and is available in all major browsers. Other features such as atomics, SIMD, reference types and many more are not as widely available (with Safari lagging behind in most of these).

The SwiftWasm team would be happy to start experimenting with atomics, SIMD, and reference types when that is possible. Atomics is a big one, as it unblocks multi-threading support with big parts of core libraries that are currently unavailable in SwiftWasm. We could then make Dispatch and major parts of Foundation available in browsers.

tomerd pitched a proposal that adds support for Package Feeds to SwiftPM.

A package feed is a curated list of packages and associated metadata which makes it easier to discover an existing package for a particular use case. SwiftPM will allow users to subscribe to these feeds, search them via the swift package command-line interface, and will make their contents accessible to any clients of libSwiftPM. This proposal is focused on the shape of the command-line interface and the format of configuration data related to package feeds.

Samuel Roth proposed a pitch that introduces an Authentication package, which will provide lightweight yet opinionated abstractions enabling developers to build secure authentication systems in Swift.

As adoption of Swift on the server continues to increase, and the server-side Swift ecosystem grows (e.g. with introduction of Swift Service Discovery), various approaches to building authentication and authorization mechanisms are likely to pop up. Swift Authentication seeks to address the former challenge.

Swift Authentication aims to address sensitive use cases that could have profound security implications. An openly-available package with good documentation (and perhaps more importantly, recommendations) made available in the IDE (Xcode or otherwise) could make Swift an even more attractive solution for building services with authentication requirements.

Dario Rexin pitched an idea for codable synthesis for enums with associated values.

Codable was introduced in SE-0166. with support for synthesizing Encodable and Decodable conformance for class and struct types, that only contain values that also conform to the respective protocols.

Currently auto-synthesis does not work for enums with associated values. There have been discussions about it in the past, but the concrete structure of the encoded values was never agreed upon. We believe that having a solution for this is an important quality of life improvement.

John Burkey proposed Swift Actors and performance concurrency futures.

1. Provide a course grained actor model first, which includes separate of concerns of actor functions, whose definitions live separately from Actors that register to receive those function calls async.

2. Provide a fine grained concurrency model allowing queue safe very high frequency lock free allocations, similar to a generational GC.

3. Provide a concurrency safe logging model. Concurrency safe logging isn’t just not crashing- its safe and performantly managing high frequency logging on n concurrent threads.

Robert MacEachern started a conversation about Swift’s value type thread safety and John McCall told that Swift team is making data races statically impossible as much as possible.

Steven Van Impe shared a Swift Setup - student-friendly setup instructions for platforms, editors, and IDEs that support Swift.

This repository gathers student-friendly setup instructions for platforms, editors, and IDEs that support Swift. The goal of this repository is to support the adoption of Swift as a general purpose cross-platform programming language in (higher) education.

To kickstart the repository, I’ve written instructions for the platforms and editors I’m using in an upcoming programming course, notably Visual Studio Code (with SourceKit-LSP and CodeLLDB) on Ubuntu.

Bradley Mackey pitched a proposal to add platform aliases.

The least disruptive and backwards compatible solution appears to be Platform Aliasing, which can reduce an annotation like this…

@available(macOS 10.16, iOS 14.0, watchOS 7.0, tvOS 14.0, *)

…to something as simple as this…

@available(apple 2020, *)

Finally

These Great British Bake Off challenges are getting tough.

RC or GM?