The last two weeks passed by so quickly! I’ve been busy with a new project, launching this week, and I’ve been exploring SwiftUI 2 new features like LazyVStack, LazyHGrid, @StateObject and more. So far, I love it a lot.

In the interim, Apple released Xcode 12.5 Beta, which includes many important additions and fixes for the Swift language. We still need to wait a little longer for async/await, but it’s getting closer.

As always, thank you for supporting this newsletter. We are looking for all kinds of assistance - financial, putting together new issues, or contributing to improve the site. If there’s something you think you can do, we’d love to hear from you.

Now, straight to the news!

Starter tasks

News and community

Xcode 12.5 Beta has been released with some new and notable Swift features and issues resolved.

Tomer Doron announced Swift 5.3.3 for Linux and Windows.

Paul Hudson wrote an article explaining what’s new in Swift 5.4.

Commits and pull requests

Andrew Trick merged a pull request that adds PhiOperand and PhiValue types.

Adrian Prantl merged a pull request that adds debug info support for boxed arguments in async functions and fixes SR-14059.

Doug Gregor merged a pull request that enables async/await by default.

Returned proposals

SE-0299 has been returned for revision.

The review period for SE-0299: Extending Static Member Lookup in Generic Contexts has concluded. The core team has decided to return this proposal for revision. We agree that extending .leadingDot contextual member lookup to work in generic contexts fits well with the direction of Swift, and that extending it to find members from protocol extensions corresponding to constraints on the generic context is a reasonable incremental expansion of the existing model. However, the core team is concerned about the potential for namespace pollution when using this new feature as exemplified in the proposal, an issue the review discussion also raised concerns about, and would like to see the proposal revised to address this concern.

SE-0295 has been returned for revision.

We agree that having a default Coding synthesis for enums with payloads is valuable. Although the encoding may not be perfect for every use case, the default encoding is still valuable as it simplifies the cases where the encoding is sufficient. For the other use cases, the user is still able define the synthesis as they could previously.

Furthermore, the extensibility of Codable is beyond the scope of this proposal as is the “readability” of the serialization itself. The design choices of Codable are not grounds for preventing improvements to serialization in Swift.

Proposals in review

SE-0300: Continuations for interfacing async tasks with synchronous code is under the second review.

Asynchronous Swift code needs to be able to work with existing synchronous code that uses techniques such as completion callbacks and delegate methods to respond to events. Asynchronous tasks can suspend themselves on continuations which synchronous code can then capture and invoke to resume the task in response to an event. … Following the first review of this proposal, the core team feels that this is a good addition to the language, and is an important feature as part of Swift’s concurrency roadmap. However, a number of clarifications to the proposal resulted from the first review, and so a second review of this clarified proposal is being conducted.

SE-0301: Package Editor Commands is under a review.

Because Swift package manifests are written in Swift using the PackageDescription API, it is difficult to automate common tasks like adding a new product, target, or dependency. This proposal introduces new swift package subcommands to perform some common editing tasks which can streamline users’ workflows and enable new higher-level tools.

SE-0299: Extending Static Member Lookup in Generic Contexts is under the second review.

Using static member declarations to provide semantic names for commonly used values which can then be accessed via leading dot syntax is an important tool in API design, reducing type repetition and improving call-site legibility. Currently, when a parameter is generic, there is no effective way to take advantage of this syntax. This proposal aims to relax restrictions on accessing static members on protocols to afford the same call-site legibility to generic APIs.

Swift Forums

Doug Gregor updated us about about the third Actors pitch.

After yet more interesting discussion in pitch #2, we’ve revised the actor proposal for this, pitch #3.

Changes in the third pitch:

  • Narrow the proposal down to only support re-entrant actors. Capture several potential non-reentrant designs in the Alternatives Considered as possible future extensions.
  • Replaced @actorIndependent attribute with a nonisolated modifier, which follows the approach of nonmutating and ties in better with the “actor isolation” terminology (thank you to Xiaodi Wu for the suggestion).
  • Replaced “queue” terminology with the more traditional “mailbox” terminology, to try to help alleviate confusion with Dispatch queues.
  • Introduced “cross-actor reference” terminology and the requirement that cross-actor references always traffic in ConcurrentValue types. This goes along with the latest pitch on ConcurrentValue.
  • Reference @concurrent function types from their separate proposal (which his the same proposal as ConcurrentValue).
  • Moved Objective-C interoperability into its own section.
  • Clarify the “class-like” behaviors of actor types, such as satisfying an AnyObject conformance.

Chris Lattner pitched the fourth draft of ConcurrentValue and @concurrent closures Evolution.

Thank you for all the great feedback on the proposal. Doug and I have been iterating on it a bit and have a draft #4 up. My sense is that this is getting close to convergence for a formal review.

John McCall pitched an idea to add support custom executors in Swift concurrency.

It is sometimes important to control exactly how code is executed. This proposal lays out a system of custom executors which can schedule and run opaque jobs, and it describes how actors and tasks can be directed to run on a specific executor.

Motivation Swift’s concurrency design is intentionally vague about the details of how code is actually run. Most code does not rely on specific properties of the execution environment, such as being run to a specific operating system thread, and instead needs only high-level semantic properties, such as that no other code will be accessing certain variables concurrently. Maintaining flexibility about how work is scheduled onto threads allows Swift to avoid certain performance pitfalls by default.

Joe Groff informed us about another revision of the Structured Concurrency proposal.

Chris Lattner expressed his concerns about the actor proposal.

Morten Bek Ditlevsen pitched an idea that solves an issue with the current state of Dictionary encoding and decoding.

The current conformance of Swift’s Dictionary to the Codable protocols has a somewhat-surprising limitation in that dictionaries whose key type is not String or Int (values directly representable in CodingKey types) encode not as KeyedContainers but as UnkeyedContainers. This behavior has caused much confusion for users and I would like to offer a way to improve the situation.

George proposed a solution for how to fix the issue of automatic Codable synthesis for enums with associated types.

I think we can solve both of these issues by introducing four new codable container types: Tagged{En,De}codingContainer<Tag>, and Tuple{En,De}codingContainer<Tag>.

Finally

Typical swifts.