Let’s start with the most important news: Swift 5.4 has been released alongside Xcode 12.5. It has some notable new features and additions like result builders, multiple variadic parameters, and more.

WWDC is just one month away! Who knows, maybe this is the reason why so many Swift Evolution proposals are in review or have been accepted?

For the last couple of weeks I have been pretty swamped with work, and I’m glad that I’m not alone on this project. If you want to get involved, or your company wants to sponsor, it would be very much appreciated. Thank you, everyone!

Starter tasks

  • SR-14587 refactor-check-compiles should generate both -dump-text and dump-rewritten from a single swift-refactor invocation

News and community

Ted Kremenek wrote a blog post about the release of Swift 5.4.

Federico Zanetello wrote an article explaining what’s new in Swift Package Manager in Swift 5.4.

Alexander Steiner created a Docker Client written in Swift. It uses the NIO Framework to communicate with the Docker Engine via sockets.

Vincent Pradeilles created a video to walk us through what’s new in Swift 5.4.

Commits and pull requests

Erik Eckstein created a pull request that starts implementing SIL optimizations in Swift.

Tim Condon created a pull request that adds support for async/await to Vapor.

Accepted proposals

SE-0306 Actors was accepted with modification.

For this second review, we had asked the community to explore the question of whether let bindings should be exceptional in their default actor isolation behavior, and based on community feedback, the Core Team has accepted the proposal with the modification that let bindings should be isolated by default, consistent with what is proposed for other declarations. Several topics, in addition to isolation of lets, came up in the second review…

SE-0303 Package Manager Extensible Build Tools was accepted.

The second review of SE-0303 has concluded. Feedback in the first review was positive and feedback from the second review has been largely informational. The proposal is accepted with some minor clarifications (diff).

SE-0305 Package Manager Binary Target Improvements was accepted.

The second review of SE-0305 has concluded. Feedback in the first review was positive and feedback from the second review has been largely informational. The proposal is accepted with some minor clarifications (diff).

SE-0310 Effectful Read-only Properties was accepted.

The Core Team considered a number of points that came up in the discussion:

  • There was some discussion about the placement of effects specifiers (async and throws), with a request to move the specifiers to the property declaration itself rather than being specified on the getter. The proposal author has clarified why the proposed syntax is the appropriate syntax. The proposal will be amended with this rationale.
  • It was noted that further extension of effects to writable properties would make it hard for users to separate the getter and setter declarations

SE-0308 postfix #if config expressions was accepted.

Beyond the enthusiastic positive response, there was additional interest in further enhancements in the same direction. The core team believes that additional refinement of conditional compilation is something that the language would benefit from. As such, proposals extending support towards conditional compilation of repeated lexical constructs, e.g. elements within an array literal, would be welcome. For non-repeated constructs, there are potential issues with the parsing, for example in the removal of a binary operator may change the operator precedence of subsequent expressions, and this would require careful, deliberate handling. Such a change is not unreasonable, but would demand an appropriate level of design and care towards an implementation.

SE-0309 Unlock Existentials for All Protocols was accepted.

There was a lot of enthusiasm for removing the infamous “protocol can only be used as a generic constraint because it has Self or associated type requirements” restriction, and the Core Team agrees that at this point in Swift’s development, it serves no technical purpose, and the problems it causes are worse than the ones it tries to avoid. The Core Team also acknowledges that this proposal by itself does not solve all the problems with existentials in Swift, but that it is important progress in unblocking further improvements to generics and existentials going forward.

Proposals in review

SE-0312: Add indexed() and Collection conformances for enumerated() and zip(_:_:) is under a review.

This proposal aims to fix the lack of Collection conformance of the sequences returned by zip(_:_:) and enumerated(), preventing them from being used in a context that requires a Collection. Also included is the addition of the indexed() method on Collection as a more ergonomic, efficient, and correct alternative to c.enumerated() and zip(c.indices, c).

Swift-evolution thread: Pitch

SE-0311: Task-local values is under a second review.

The first review received a lot of very useful feedback. In response, the author has made major changes to the proposal. The Core Team has decided to put up the revised proposal for de novo review; that is, you should essentially review this proposal as if it were an entirely different proposal.

SE-0313: Improved control over actor isolation is under a review.

The Swift actors proposal introduces the notion of actor-isolated declarations, which are declarations that can safely access an actor’s isolated state. In that proposal, all instance methods, instance properties, and instance subscripts on an actor type are actor-isolated, and they can synchronously use those declarations on self. This proposal generalizes the notion of actor isolation to allow better control, including the ability to have actor-isolated declarations that aren’t part of an actor type (e.g., they can be non-member functions) and have non-isolated declarations that are instance members of an actor type (e.g., because they are based on immutable, non-isolated actor state). This allows better abstraction of the use of actors, additional actor operations that are otherwise not expressible safely in the system, and enables some conformances to existing, synchronous protocols.

Swift Forums

Doug Gregor pitched a proposal that adds a better way to initiate asynchronous work from synchronous code. You can read the full proposal here.

Swift async functions can only directly be called from other async functions. In synchronous code, the only mechanism provided by the Swift Concurrency model to create asynchronous work is detach. The detach operation creates a new, detached task that is completely independent of the code that initiated the detach: the closure executes concurrently, is independent of any actor unless it explicitly opts into an actor, and does not inherit certain information (such as priority).

Samuel McBroom pitched an idea to add isPrependConcatenationMark to Unicode.Scalar.Properties.

Swift’s Unicode.Scalar.Properties struct includes many useful property checks for scalars, such as isAlphabetic, isHexDigit, etc. I think including a new isPrependConcatenationMark property check would also be useful, corresponding to the Prepend_Concatenation_Mark property listed in the Unicode Standard.

Swift on the Server Workgroup meetings:

Philippe Hausler pitched a proposal: Continuations for interfacing async tasks with synchronous code.

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.

Swift-evolution thread:

Finally

There is only one use case for AirTags.