Big announcement this week: WWDC21 will happen from June 7 to 11. It will be online only, so everyone in our community can join in on the fun.

Kristaps asked me to take care of the newsletter this week. So hi, my name is Jeroen and I recently got involved with Swift Weekly Brief by running some infrastructure. Writing for you all is a bit of a leap for me, so let us know what you think!

Just like in issue 181 I will start by mentioning the wonderful work being done to build a more inclusive Swift developer ecosystem: Diversity in Swift.

As always Swift Evolution is moving fast. Quite a few interesting proposals have been accepted, and a number of interesting pitches have been proposed. On top of that, we’ve decided to add a community section below, to highlight a few members whose work we think you will like.

Thank you so much for reading, and enjoy issue 182.

Interested in sponsoring Swift Weekly Brief? Learn more here.

Starter tasks

SR-14443 [Compiler] [C++] Don’t crash on invalid dependent values.

News and community

Check out the new Swift Collections package, a new open-source package focused on extending the set of available Swift data structures. Like the Swift Algorithms and Swift Numerics packages before it, it is being released to help incubate new functionality for the Swift Standard Library. Join the conversation on Swift Collections on the Swift forums.

The Swift Standard Library currently implements the three most essential general-purpose data structures: Array, Set and Dictionary. These are the right tool for a wide variety of use cases, and they are particularly well-suited for use as currency types. But sometimes, in order to efficiently solve a problem or to maintain an invariant, Swift programmers would benefit from a larger library of data structures.

Vincent Pradeilles creates great videos relevant to Swift developers. Here’s a few you might like to try: Exploring Swift Evolution Proposals, What’s the difference between Swift error mechanisms and Why Never is such a special type.

Jesse Squires, the original founder of this newsletter, has done some digging on why Swift Closures are not equatable.

Accepted proposals

SE-0285 Ease the transition to concise magic file strings was accepted

The feedback was generally positive, and to address the concern around which variants of #file library authors should use the proposal was modified to include Swift API Design Guidelines amendment encouraging library authors to prefer #fileID over alternatives.

SE-0296 async/await was accepted with modification

Feedback was very positive on the concept of adding async/await in general with a few key points raised. Read about those points in the forum post.

SE-0307 Allow interchangeable use of CGFloat and Double types was accepted

After careful consideration of the thoughtful discussion during the review and pitch threads, the Core Team has decided to accept SE-0307. The Core Team recognizes this was a divisive topic.

SE-0300 Continuations for interfacing with async was accepted

The third review of SE-0300 has concluded. Feedback in the third round of review was positive. The proposal is accepted with some minor clarifications (diff).

SE-0293 Extend Property Wrappers to Function and Closure Parameters was accepted

The third review of SE-0293 has concluded. Feedback in the third round of review was quite positive, a result of the great iteration from the previous rounds of proposal. As such, the core team has accepted the proposal as written.

SE-0302 Sendable and @Sendable closures was accepted

Feedback in the second round of review was generally positive. There was a fair amount of discussion about the new names, and people seemed to generally approve of the name Sendable for the protocol. Consensus was weaker about the name @sendable for the function-type attribute.

SE-0298 Async/Await: Sequences amendment accepted

The Core Team has accepted an amendment to SE-0298 that clarifies the end-of-iteration behavior.

Returned proposals

SE-0303 Package Manager Extensible Build Tools was returned for revision

The feedback to idea of extending SwiftPM with plugins, the concrete design of the plugin system, and the tradeoffs the design make was very positive. Both authors and users of potential future plugins have provided input that the proposed design would work in real-world use cases, and that today require solutions outside of SwiftPM. However, there were a number of ideas that came up during the review that the core team feels would be good to adopt.

Proposals in review

SE-0304 (2nd review): Structured Concurrency is under review

The first review received largely positive comment, but led to a number of revisions, particularly regarding naming of methods. You can find a diff for the revision here.

This review is part of the large concurrency feature, which we are reviewing in several parts. While we’ve tried to make it independent of other concurrency proposals that have not yet been reviewed, it may have some dependencies that we’ve failed to eliminate. Please do your best to review it on its own merits, while still understanding its relationship to the larger feature. You may also want to raise interactions with previous already-accepted proposals – that might lead to opening up a separate thread of further discussion to keep the review focused.

SE-0308 #if for postfix member expressions is under review

SE-0292 Package Registry Service under 2nd review

Based on the feedback from the first review, the core team feels confident that the ideas behind Package Registry Service are useful and put the Swift packages ecosystem on the right path. One key area the core team asked to further explore in response to the first review, was the nature of the package identifiers given their potential utility in addressing Swift module name conflicts.

Swift Forums

As always, there are lots of pitches going on. Here are some that peaked my interest:

Finally