I want to thank Jeroen for helping out with last week’s issue. He did a great job spicing up the usual flow. How did you like it? Let us know.

We finally have the Xcode 12.5 RC, and it has some notable Swift language fixes and improvements.

In the last two weeks it seems like the Swift core team have woken up after a winter slumber. Dozens of proposals are now in review and many have been returned.

Now let’s go to the news!

News and community

Xcode 12.5 RC is out and has a lot of new Swift features, improvements, and fixes.

Vincent Pradeilles created a video explaining why we should read Swift Evolution Proposals.

Leonardo Maia Pugliese wrote an article exploring the single forward pipe operator in Swift.

Mishal Shah informed us that Swift 5.5 nightly development snapshots are now available.

Commits and pull requests

David Goldman created a pull request that adds support for clangd’s semantic highlighting.

Slava Pestov merged a pull request that fixes the issue where SIL type lowering did not commute with subst().

Joakim Hassila created a pull request that adds support for io_uring for the SwiftNIO project.

Cory Benfield merged a pull request that adds async/await support to the SwiftNIO.

Saleem Abdulrasool created a pull request that adds backtrace support for Windows.

Returned proposals

SE-0305 has been returned for revision.

The feedback to the idea of extending SwiftPM to support new kind of binary targets, in conjunction with the plugin system proposed in SE-0303 was positive. However, given SE-0303 was returned to review, as well as feedback from reviewers requesting additional details on the structure suggested on SE-0305, the core team decided to ask that SE-0305 is refined alongside SE-0303.

Proposals in review

SE-0306: Actors is under a second review.

The core team sees two competing draws for consistency here—first, as Chris notes, in other places where Swift models API design, let is externally treated equivalently with a get-only var, and by that principle, actors should follow suit and not expose lets as implicitly nonisolated outside of the actor even if they are immutable. That would reserve for the actor the ability to evolve the interface into an internally-mutable variable, or get-only computed property, without breaking API or ABI. It would also result in a consistent rule for how isolated and nonisolated apply to actor members; instead of lets being a special case, any actor declaration would require nonisolated to be explicitly annotated to declare it as safe to access from outside the actor without isolation.

On the other hand, “lets are immutable and safe to share across threads” has also been a common message through Swift’s history, and it could seem boilerplatey to require an explicit annotation on top of let to say that, yes, this immutable value is actually immutable. If actors in practice end up carrying a lot of immutable state, the annotation burden could be onerous. The core team would like to hear from the community, particularly adopters who have experimented with actors, to get more signal about how much burden treating the isolation lets equivalently with other declarations will be in practice.

SE-0310: Effectful Read-only Properties is under a review.

Nominal types such as classes, structs, and enums in Swift support computed properties and subscripts, which are members of the type that invoke programmer-specified computations when getting or setting them. The recently accepted proposal SE-0296 introduced asynchronous functions via async, in conjunction with await, but did not specify that computed properties or subscripts can support effects like asynchrony. Furthermore, to take full advantage of async properties, the ability to specify that a property throws is also important.

SE-0305: Package Manager Binary Target Improvements is under a second review.

The Swift Package Manager’s binaryTarget type lets packages vend libraries that either cannot be built in Swift Package Manager for technical reasons, or for which the source code cannot be published for legal or other reasons.

In the current version of SwiftPM, binary targets only support libraries in an Xcode-oriented format called XCFramework, and only for Apple platforms.

SE-0303: Package Manager Extensible Build Tools is under a second review.

This is a proposal for extensible build tools support in Swift Package Manager. The initial set of functionality is intentionally basic, and focuses on a general way of allowing build tool plugins to add commands to the build graph. The approach is to:

  • provide a scalable way for packages to define plugins that can provide build-related capabilities
  • support a narrowly scoped initial set of possible capabilities that plugins can provide

The set of possible capabilities can then be extended in future SwiftPM versions. The goal is to provide short-term support for common tasks such as source code generation, with a design that can scale to more complex tasks in the future.

This proposal depends on improvements to the existing Binary Target type in SwiftPM — those details are the subject of the separate proposal SE-0305.

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

This proposal is part of the larger concurrency feature. There have been quite a lot of these reviews, and there are a quite a few more coming, I’m afraid; still, we seem to have got through most of the more difficult ones. Thank you for your patience with all this.

SE-0309: Unlock existential types for all protocols is under a review.

Swift allows one to use a protocol as a type when its requirements meet a rather unintuitive list of criteria, among which is the absence of associated type requirements, and emits the following error otherwise: Protocol can only be used as a generic constraint because it has 'Self' or associated type requirements. Our objective is to alleviate this limitation to impact only the ability to access certain members (instead of preemptively sealing off the entire protocol interface), and adjust the specified criteria to further reduce the scope of the restriction.

This proposal is a preamble to a series of changes aimed at generalizing value-level abstraction (existentials) and improving its interaction with type-level abstraction (generics). For an in-depth exploration of the relationships among different built-in abstractions models, we recommend reading the design document for improving the UI of the generics model.

Swift-Evolution Pitch Threads: Thread #1, Thread #2

Swift Forums

Tim Vermeulen pitched a proposal to add indexed() and Collection conformances for enumerated() and zip(_:_:).

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).

Jonathan G. started an interesting discussion about making the “Undocumented/Private API” signifier _ official.

There is an undocumented convention in Swift, of appending an underscore “_” to a public symbol or attribute to communicate some special meaning.

However, you will not find any mention of this practice within Swift’s own documentation on swift.org, nor any explanation of the often subtle differences in meaning of “_”. (Please correct me if I’m wrong. I did several searches and came up with nothing, and several read-throughs.)

Kelvin Ma started a discussion about why Dictionary[position:] is not settable?

The Dictionary type exposes a non-nil subscript [position:] which takes a Dictionary.Index. I always wondered why this subscript is get-only, since I often find myself wanting to check if a key-value pair is present in the dictionary, and then mutate the value only if it exists.

Swift on the Server Workgroup meeting notes:

Finally

When you forget to get rid of your debugging statements