We’re starting today’s newsletter with some hiring news from Apple: they are looking for paid interns for their language, compiler and debugger teams. Even if you don’t have experience in the specific field, interested students are encouraged to apply anyway. If you’d like to understand better how internships work, have a look at this insightful article about Amritpan Kaur’s path through Compiler Development and Language Design.

There have been some really nice improvements made to Swift.org recently, including support for dark mode. For those of you using dark mode on iOS, the website will automatically switch modes to match. I hope you’re enjoying this feature as much as I am.

As always, I want to express our appreciation for the support from our sponsors. Without you this newsletter wouldn’t exist, so thank you very much. If anyone else is interested in sponsorship, please kindly get in touch. More information on how you could participate in our project can be found here.

Starter tasks

SR-15271 [Compiler] Improve Codable Diagnostics When CodingKeys Do Not Match Properties

News and community

Ted Kremenek wrote a post about the Swift 5.5 release.

Bruno Rocha published a great article explaining how AsyncSequence works internally in Swift.

Lee Kah Seng wrote a cool article describing the actor reentrancy problem in Swift.

Amritpan Kaur explained how she participated in the inaugural Swift Mentorship and worked on Compiler Development and Language Design.

Commits and pull requests

Michael Ilseman merged a pull request that implements native normalization for String.

Doug Gregor created a pull request that would back-deploy @objc actor types.

Accepted proposals

SE-0322 Temporary Uninitialized Buffers was accepted with modifications.

SE-0323 Asynchronous Main Semantics was accepted.

SE-0324 Relax diagnostics for pointer arguments to C functions was accepted.

Proposals in review

SSWG-0017: MultipartKit is under review.

MultipartKit offers both low level parsing and serializing of Multipart data as well as high level Codable support for encoding and decoding Multipart form data.

Swift Forums

Karoy Lorentey asked when should ManagedAtomic/UnsafeAtomic be marked Sendable?

I just filed issue #45, asking UnsafeAtomic, ManagedAtomic and friends to be marked Sendable, reflecting that they are safe to transfer across concurrency domains.

Kavon Farvardin proposed to define how actor initializers work in Swift.

The proposed solution to some of the problems described in this proposal are currently reflected in Swift 5.5 through a warning, but it’s important to review these changes for Swift 6. In addition, this proposal adds extra capabilities for the deinit of MainActor-isolated class, to make them easier and safer to write. I’ll paste the entire proposal below, but for the most up-to-date write-up, go here.

Kelvin Ma discovered that Swift 5.5 has serious stack corruption bugs.

I’ve discovered several stack corruption bugs related to async/await which can be reproduced in simple test programs compiled with recent nightly toolchains. i have confirmed that two three four of these bugs are present in the 5.5-RELEASE toolchain.

Becca Royal-Gordon pitched a proposal to add staging in sendable checking.

A couple weeks ago, @Douglas_Gregor pitched some changes which tried to tackle some of the problems involved in adopting Sendable checking in a module when some of your clients or dependencies may not have updated yet. I had some concerns about how that pitch’s approach might break or hide bugs when modules were eventually updated, as well as with how Objective-C libraries would be able to control the sendability of their types.

YR Chen started a discussion around solving inconsistencies with the release of Swift 6.

The arrival of Swift 6 means a chance for “regretting” some language designs with API breakage — after 3 years which is fairly a long time for Swift and the Swift community. With the Swift 3.2 and Swift 4.2 effort, transition to a breaking Swift release has proved to be a lot smoother.

I would suggest we pick up some of the deferred breaking pitches, which intended to eliminate inconsistency within the language. These ideas have already received positive feedbacks from the community, and yet didn’t make their ways into reality.

Philippe Hausler pitched a proposal to define Clock, Instant, Date, and Duration.

The concepts of time can be broken down into three distinct parts: an item to provide a concept of now plus a way to wake up after a given point in time, a concept of a point in time, and a concept of a measurement in time. These three items are respectively a clock, an instant and a duration. The measurement of time can be used for many types of APIs, all the way from the high levels of a concept of a timeout on a network connection, to the amount of time to sleep a task. Currently the APIs that take measurement of time types take NSTimeInterval aka TimeInterval, DispatchTimeInterval, and even types like timespec.

Michael Ilseman pitched an idea to implement declarative string processing APIs.

String processing is hard and the current affordances provided by the Swift Standard Library are underpowered. We propose adding two new declarative string processing APIs—a familiar Regex literal and a more powerful Pattern result builder—to help make Swift string processing fast and easy.

This is a large feature that will ultimately be divided into multiple Swift Evolution proposals. This initial pitch is intended to prompt discussion about the high level direction and to introduce the key prongs of the feature and their relationship to one another.

Kelvin Ma started a discussion around long-term-support (“LTS”) releases.

for those who don’t follow the Development topic, @mickeyl, @timdecode, and i have recently uncovered an alarming number of highly dangerous stack corruption bugs in the Swift 5.5 release toolchain.

setting aside the technical aspects of the stack corruption issues in Swift 5.5, which are detailed in the corresponding thread, i would like to kickoff discussions on whether it would be valuable for us to adopt some form of the concept of a “Long-Term Support” (LTS) release 8 in our release cycle, much like Ubuntu has been doing for some time.

Anders Bertelrud pitched a proposal to extend the plugin SwiftPM plugin API to provide more context.

SE-0303 introduced SwiftPM plugins, focusing in particular on build tool plugins (especially those that generate source code). To keep that proposal bounded, the type and amount of information available to a plugin was geared toward the task of generating build commands.

Before starting to consider new kinds of plugins, it seems prudent to expand the information available to plugins of all kinds. Future proposals might add specific APIs for particular kinds of plugins, but before that, it seems that a good starting point would be to give all plugins access to a distilled form of the package graph that SwiftPM already has internally. This should allow a wide latitude in terms of what any particular plugin wants to do.

I’d like to pitch a draft proposal for extending the API available to SwiftPM plugins, and would love to hear what everyone thinks. There’s an implementation in a PR in the SwiftPM repository.

Guillaume Lessard pitched a proposal to expand usability of withMemoryRebound.

The function withMemoryRebound(to:capacity:_ body:) executes a closure while temporarily binding a range of memory to a different type than the callee is bound to.

We propose to lift some notable limitations of withMemoryRebound and enable rebinding to a larger set of types, as well as rebinding from raw memory pointers and buffers.

Tim Condon updated us about async/await and the future of Vapor.

Drew McCormack pitched a proposal that would create standard library data structures designed for working with shared data in a concurrent system.

I want to propose such a type here: a branching resource.

A BranchingResource would be a type with a generic parameter for the payload it carries (ie the resource). The resource would begin with a single branch, called “main” or “trunk” or “truth”. The app could add as many auxiliary, named branches as it likes.

Pavel Yaskevich pitched an idea to enable multi-statement closure parameter/result type inference.

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.

Finally

typedef unsigned char BOO_L; // 👻