Issue #178 11 Feb 2021
Written by: Kristaps Grinbergs
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
@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
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!
DuckDuckGo are on the hunt for senior iOS engineers to help shape the technology that powers the DuckDuckGo search experience. If you’re an engineer that enjoys the autonomy of leading projects and questioning the status quo this could be the perfect role for you. We’re a globally distributed team so regardless of where you’re based we’d love to hear from you.
- SR-14137 [C++] Cache failed imports.
News and community
Xcode 12.5 Beta has been released with some new and notable Swift features and issues resolved.
Commits and pull requests
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
.leadingDotcontextual 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.
We agree that having a default
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
Codableis beyond the scope of this proposal as is the “readability” of the serialization itself. The design choices of
Codableare not grounds for preventing improvements to serialization in Swift.
Proposals in 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.
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 packagesubcommands to perform some common editing tasks which can streamline users’ workflows and enable new higher-level tools.
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.
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.
@actorIndependentattribute with a
nonisolatedmodifier, which follows the approach of
nonmutatingand 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
ConcurrentValuetypes. This goes along with the latest pitch on
@concurrentfunction types from their separate proposal (which his the same proposal as
- Moved Objective-C interoperability into its own section.
- Clarify the “class-like” behaviors of actor types, such as satisfying an
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.
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.
The current conformance of Swift’s
Codableprotocols has a somewhat-surprising limitation in that dictionaries whose key type is not
Int(values directly representable in
CodingKeytypes) 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.
I think we can solve both of these issues by introducing four new codable container types: