Issue #182 08 Apr 2021
Written by: Jeroen Leenarts
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
As always, there are lots of pitches going on. Here are some that peaked my interest:
- [Concurrency] YieldingContinuation
- [Pitch] Conformance Builders
- [Pitch] Introduce
let-elsesyntax as alternative for single expression
- Access control for enum cases
- Allowing @unknown in arbitrarily nested patterns