Issue #197 04 Nov 2021
Written by: Kristaps Grinbergs
How have the last two weeks been for all of you? Personally, I’ve felt a slight decrease in my working capacity due to lack of daylight and the falling temperatures. By the way, does your country use daylight savings time?
The Xcode 13.2 Beta has concurrency support, which should help to resolve a certain kind of pain-point for many Swift developers. Perhaps the most important benefit of Swift’s built-in concurrency system is that it allows performing multiple asynchronous tasks in parallel in a much easier way. I can only imagine how much time we’ll save by speeding up performing tasks.
It is with great pleasure that I write how terrific the last three years of running this newsletter have been. I’ve met so many incredible people, and thanks to all of you, I have learned so much! This is the reason why typing the following sentence fills me with emotion. Issue 200 will be the last newsletter I run. I have decided to step away from leading this project, and with joyful excitement, I am looking for someone who would like to continue running things.
NSSpain 2021 Remote Edition is an online, continuous 36 hours conference, carefully crafted by the community for the community.
SR-15408 [Swift-DocC ] Building documentation with a fallback display name that includes a space produces a broken-looking article
News and community
New Xcode 13.2 Beta adds Swift Concurrency support for macOS 10.15, iOS 13, tvOS 13, and watchOS 6 or newer. This support includes
async/await, actors, global actors, structured concurrency, and the task APIs.
Swift download links have moved to a new location to provide faster download speeds! The toolchains will be hosted at download.swift.org, and it will use a similar pattern as the current URL. To use the new URL, replace
download.swift.org/. Starting Oct 26th 2021, the
swift.org/builds URLs have been redirected to the new sub domain.
Commits and pull requests
Proposals in review
I propose to improve inference behavior of multi-statement closures by enabling parameter and result type inference from the closure body. This will make type inference less surprising for developers, and remove the existing behavior cliff where adding one more expression or statement to a closure could result in a compilation failure.
Actors are a relatively new nominal type in Swift that provides data-race safety for its mutable state. The protection is achieved by isolating the mutable state of each actor instance to at most one task at a time. The proposal that introduced actors (SE-0306) is quite large and detailed, but misses some of the subtle aspects of creating and destroying an actor’s isolated state. This proposal aims to shore up the definition of an actor, to clarify when the isolation of the data begins and ends for an actor instance, along with what can be done inside the body of an actor’s
An opaque result type may be used as the result type of a function, the type of a variable, or the result type of a subscript. In all cases, the opaque result type must be the entire type. This proposal recommends lifting that restriction and allowing opaque result types in “structural” positions.
SE-0303 introduced the first kind of SwiftPM plugins, focusing on the ability to extend the build system with custom build tool invocations (in particular for the purpose of generating source code). Those plugins were always intended to be just the first kind of plugin supported by SwiftPM.
I’d like to pitch a draft proposal for adding another kind of more general-purpose “command plugin” to SwiftPM. These kinds of plugins would be directly invocable by users and would be intended for such things as source code formatting, documentation generation, test report generation, etc. A command plugin would not necessarily have anything to do with the build system.
One important aspect of these custom command plugins is that they can ask the plugin host (either SwiftPM or an IDE that supports packages) to generate specialized information on-demand or to initiate builds or test runs. This is the part of the draft proposal that could use the most scrutiny. There is an element of tension here between making the API rich enough to be as useful as possible, while also making it generic enough to be implementable not only in SwiftPM but also in IDEs that support Swift Packages.
Guillaume Lessard pitched a proposal that would implement pointer family initialization improvements.
The types in the
UnsafeMutablePointerfamily typically require manual management of memory allocations, including the management of their initialization state. The states involved are, after allocation:
- Unbound and uninitialized (as returned from
- Bound to a type, and uninitialized (as returned from
- Bound to a type, and initialized
Memory can be safely deallocated whenever it is uninitialized.
Unfortunately, not every relevant type in the family has the necessary functionality to fully manage the initialization state of its memory. We intend to address this issue in this proposal, and provide functionality to manage initialization state in a much expanded variety of situations.
is there any way we can add an API to
AsyncStreamwhich returns the continuation directly, so we do not have to “juggle” it out of the closure?
in general, i also feel like
AsyncStreamis really difficult to work with due to the requirement that iteration happen in the same Task that the
AsyncStreamwas created in, even when no concurrent iteration ever takes place. this makes it hard to “subscribe” to events generated from
actorobjects, even when the subscription method is marked
MQTT is a messaging protocol commonly used for communicating with IoT (Internet of Things) devices. It is a lightweight publish/subscribe message transport designed to have a small code footprint and network bandwidth.
The SwiftNIO team has made it a major pillar of our workflow to attempt to support Swift releases for a reasonably long time. Most users don’t take advantage of this, preferring to stay on the most recent release of Swift, but we think it’s important that you have confidence that newly written applications will get some meaningful amount of support going forward.
DocC is currently architected to render symbol documentation in a single language (Swift). However, there are cross-language projects that would benefit from collecting multiple “language variants” together into the same set of documentation, for example for Objective-C APIs that can be called from Swift or vice-versa.