In every end, there is also a beginning.

This issue #200 is my last as the main contributor to this project. I want to thank Jesse Squires, who started this project, and Bas Broek, who continued later on and trusted me to run it. I also want to thank all the contributors who have helped with writing, reviewing, or providing the content. It is indeed a community-run project. Thank you!

Now let’s get to the news.

Podcasts

In episode 110 of the Swift by Sundell podcast, Tim Condon, joins John Sundell to discuss how both client and server-side Swift developers could utilize the new built-in concurrency system, as well as how distributed actors and other upcoming language features might continue to make Swift even more capable on the server.

News and community

Six years ago, on the 3rd of December 2015, the Swift language was open-sourced.

Xcode 13.2 has been released. The release tumbled a bit, but has some notable Swift features.

Swift Playgrounds 4 is now available. Swift Playgrounds is the best and easiest way to learn how to code. And with Swift Playgrounds 4, you have the tools to build iPhone and iPad apps right on iPad and submit them directly to App Store Connect.

Amazon Web Services announced that AWS SDK for the Swift programming language is now available in developer preview.

Vincent Pradeilles posted a video about Swift’s standard library.

Commits and pull requests

Alejandro Alonso merged a pull request that drops ICU.

Accepted proposals

SE-0331 Remove Sendable conformance from unsafe pointer types was accepted.

SE-0332 Package Manager Command Plugins was accepted with modifications.

Proposals in review

SE-0335: Introduce existential any is under review.

Existential types in Swift have an extremely lightweight spelling: a plain protocol name in type context means an existential type. Over the years, this has risen to the level of active harm by causing confusion, leading programmers down the wrong path that often requires them to re-write code once they hit a fundamental limitation of value-level abstraction. This proposal makes the impact of existential types explicit in the language by annotating such types with any.

SE-0336: Distributed actor isolation is under review.

With the recent introduction of actors to the language, Swift gained powerful and foundational building blocks for expressing thread-safe concurrent programs. This proposal is the first in a series of proposals aiming to extend Swift’s actor runtime with the concept of distributed actors, allowing developers leverage the actor model not only in local, but also distributed settings.

With distributed actors, we acknowledge that the world we live in is increasingly built around distributed systems, and that we should provide developers with better tools to work within those environments. We aim to simplify and push the state-of-the-art for distributed systems programming in Swift as we did with concurrent programming with local actors and Swift’s structured concurrency approach embedded in the language.

This proposal focuses on the extended actor isolation and type-checking aspects of distributed actors.

SSWG-0018: MQTTNIO Proposal is under review.

There are a number of Swift MQTT libraries out there but many are not built on top of SwiftNIO. And many only support one version of the protocol or don’t provide WebSocket or TLS connections. MQTTNIO provides all of these. The library has also recently gained new Swift concurrency APIs.

SE-0327: On Actors and Initialization is under a second review.

This proposal has undergone a number of revisions in response to feedback from the first review 1, which the author has summarized as:

  1. Actor initializers that are not isolated to the actor will now allow you to do anything you normally can from a nonisolated method. In exchange, Swift will automatically reject accesses to stored properties that might be unsafe. Here is the problem description and proposed solution 3.
  2. Deinitializers of an actor can no longer access non-sendable stored properties of the instance. Here is the problem description and proposed solution 1
  3. The default value of a type’s stored property is evaluated in a non-isolated context. Here is the problem description and proposed solution
  4. The convenience keyword is no longer required to define a delegating initializer of an actor. Here is the problem description and proposed rules for their delegating initializers, which is continued in the Sendability section.

Swift Forums

Evan Wilde pitched a proposal the @unavailableFromAsync attribute.

The Swift concurrency model allows tasks to suspend and resume on different threads. While this behaviour allows higher utility of computational resources, there are some nasty pitfalls that can spring on an unsuspecting programmer. One such pitfall is the undefined behaviour from unlocking a pthread_mutex_t from a different thread than the thread that holds the lock. Reading from and writing to thread-local storage across suspension points can also result in unintended behavior, since the operation may be resuming on a different thread.

Tom Doron pitched an idea to statically link Swift runtime libraries by default on supported platforms.

Swift 5.3.1 introduced statically linking the Swift runtime libraries on Linux. With this feature, users can set the --static-swift-stdlib flag when invoking SwiftPM commands (or the long form -Xswiftc -static-stdlib) in order to statically link the Swift runtime libraries into the program.

On some platforms, such as Linux, this is often the preferred way to link programs, since the program is easier to deploy to the target server or otherwise share.

This proposal explores making it SwiftPM’s default behavior when building executable programs on such platforms.

Frederick Kellison-Linn pitched a proposal to reconsider @escaping for optional function-type parameters.

Kavon Farvardin updated the proposal on Actors and Initialization.

Since the proposal differs significantly from the first review, this is a pitch. Here’s a very informal and incomplete summary of the major functionality proposed, along with some links into the document itself for more details:

  1. Actor initializers that are not isolated to the actor will now allow you to do anything you normally can from a nonisolated method. In exchange, Swift will automatically reject accesses to stored properties that might be unsafe. Here is the problem description 2 and proposed solution 1.
  2. Deinitializers of an actor can no longer access non-sendable stored properties of the instance. Here is the problem description 1 and proposed solution
  3. A type’s stored property cannot have a default value if its isolation is not compatible with its initializers. Here is the problem description and proposed solution
  4. The convenience keyword is no longer required to define a delegating initializer of an actor. Here is the problem description 3 and proposed rules 2 for their delegating initializers, which is continued in the Sendability section.

Updates from Swift on the Server Workgroup:

Finally

This time I will leave my website in the final section.