Issue #187 17 Jun 2021
Written by: Kristaps Grinbergs
WWDC21 is over and it was a crazy week - full of new stuff, great sessions and things to learn during the summer. What were your favorite sessions?
If you have thoughts on how to make next year’s WWDC even better, you can express them here.
I loved all the sessions about Swift concurrency and the new SwiftUI stuff, but I haven’t watched them all. Don’t worry if you haven’t seen everything. We’ll have time to consume and learn all this new stuff. Take it easy and enjoy!
We are looking for sponsors for Swift Weekly. You can find all the information about sponsorship here.
We have a jam-packed issue this time, so let’s get to it!
Interested in sponsoring Swift Weekly Brief? Learn more here.
SR-14720 [Compiler] Mismatched
@escapingfor closure parameter produces inaccurate diagnostic
In episode 99 of the Swift by Sundell podcast, Doug Gregor joins John Sundell to discuss Swift 5.5’s new concurrency features in great detail. How do features like async/await and actors work under the hood, and how were those concepts adapted in order to feel right at home within Swift’s existing ecosystem? That, and much more, on this WWDC21 special episode of the show. Worth to read this Twitter thread about this same topic.
News and community
Doug Gregor wrote a post about Concurrency in Swift 5 and 6.
A great Twitter thread by Peter Friese about Swift concurrency in condense way.
Commits and pull requests
Proposals in review
In order to clearly separate the roles of transforming an existing directory of source files into a Swift package, from creating a new package from scratch we propose adding a new command
swift package create.
swift package initwill continue to exist as is, but will be updated to focus on the former, while the new
swift package createwill focus on the latter.
SE-0291 signing section currently says Apple Distribution certificates from developer.apple.com satisfy all of the signing certificate requirements stated in the proposal. There are details about these certificates that need to be worked out further, so in the meantime we are removing this statement from the proposal.
The technical requirements for signing certificates, and the mechanism to sign package collections remain unchanged.
- The return type of the
indexed()method has been renamed from
- The conditional
Zip2Sequencehas been removed in favor of a new
zip(_:_:)overload for random-access collections that returns a new
Zip2RandomAccessCollectiontype, due to implementation difficulties. This has been elaborated on in the Alternatives considered.
Concurrency requires runtime support that does not backward deploy. The release notes imply that this is an “issue” that just needs to be fixed. It’s not. It’s a feature that would need to be implemented. At this time, folks should assume that concurrency does not backward deploy. That said, everyone is aware of the value of it doing so, and is something that is being explored/considered.
In C, you may pass mutable pointers (specifically,
Type *) to calls expecting immutable pointers (
const void *,
const Type *). This access is safe and conventional as immutable access to a pointer’s memory can be safely assumed when you have mutable access. The same reasoning holds true for Swift but no such implicit cast to immutable counterparts exists. Instead, you must explicitly cast mutable unsafe pointer types (
UnsafeMutablePointer<Type>) to immutable versions (
UnsafePointer<Type>). This adds unneeded friction when passing mutable pointers to C functions or comparing pointers of differing mutability.
Many of the UI related use of blocks requires the developer to add lots of boilerplate code to allow weak capturing of self and other variables used in the scope of the block when updating the UI to avoid retain cycles. It also doesn’t make sense to strongly capture the UI only for updating it if its already dismissed.
By introducing the new syntax to weakly capture all variables in the scope we can also avoid bugs caused by the default behaviour of implicitly strong capturing all variables in the block scope.
This moves the focus away from deciding if strongly capturing a variable in this block will cause a retain cycle or not to letting the developer focus on whether this block must execute or is the block optional and should only be executed if all of its non optional capture list still exists.
My pitch is to allow
catchto be declared after a throwing function with a preceding
try?keyword to expose any resulting error.
I did view the behind-the-scenes talk and have tried to keep up with the discussions in various threads, but there are a few questions I have:
- It is still is unclear to me how the default executor keeps its pool of threads around and how threads are both created and woken up to get started to work. Is this fundamentally just a pool of pthreads which are woken up with the usual mechanisms, or something else? I understand the non-blocking (possible) out-of-order continuation execution, but how are things bootstrapped at a lower level? Where can I find out more about that (source pointers are fine :-) ) - I am curious as there was a comment about the performance characteristics being unknown on e g. Linux and I’d like to understand more and see if there is some work that needs to be done there. (Possible that it would require support for custom executors)
- Same goes for thread shutdown when no more work is around (so basically, how are the threads managed in the default executor)