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.

Starter tasks

SR-14720 [Compiler] Mismatched @escaping for closure parameter produces inaccurate diagnostic

Podcasts

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

Concurrency

https://docs.swift.org/swift-book/LanguageGuide/Concurrency.html guide.

Doug Gregor wrote a post about Concurrency in Swift 5 and 6.

Ben Cohen is asking feedback about Swift concurrency.

A great Twitter thread by Peter Friese about Swift concurrency in condense way.

Tom Doron wrote a blog post introducing Swift package collections.

Commits and pull requests

Doug Gregor merged a pull request that introduces the GlobalActor protocol to describe global actors.

Evan Wilde merged a pull request that fixes actor init diagnostic.

Mishal Shah merged a pull request that adds support to Xcode 13 beta.

Alastair Houghton merged a pull request that fixes demangling of optionals containing function types.

Proposals in review

SE-0318: Package Creation is under 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 init will continue to exist as is, but will be updated to focus on the former, while the new swift package create will focus on the latter.

Swift Forums

Tom Doron updated us about SE-0291: Package Collections status.

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.

Tim Vermeulen updated us about the second pitch of the indexed() proposal.

  • The return type of the indexed() method has been renamed from Indexed to IndexedCollection.
  • The conditional RandomAccessCollection conformance of Zip2Sequence has been removed in favor of a new zip(_:_:) overload for random-access collections that returns a new Zip2RandomAccessCollection type, due to implementation difficulties. This has been elaborated on in the Alternatives considered.

Alejandro Martinez asked a if Swift Concurrency is going to be compatible with older OS versions. Ted Kremenek replied:

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.

Bastian Inuk Christensen pitched an idea to conform the ResultBuilder to ExpressibleByFunctionLiteral.

John Holdsworth pitched an idea that adds automatic conversion from mutable unsafe pointers to their immutable counterparts.

In C, you may pass mutable pointers (specifically, void *, 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 (UnsafeMutableRawPointer and UnsafeMutablePointer<Type>) to immutable versions (UnsafeRawPointer and UnsafePointer<Type>). This adds unneeded friction when passing mutable pointers to C functions or comparing pointers of differing mutability.

Tomer Even pitched an idea for special syntax for blocks that capture all variables as weak.

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.

Kelvin Ma let us know that the Atomic Blonde syntax highlighter is back.

The atomic-blonde syntax highlighter for the Atom text has been out-of-commission for the last few months due to source-breaking changes in the V8 javascript engine, but I’ve just updated it to work with the latest version of node-gyp and V8.

Jacob Caraballo pitched a proposal that exposes error for try? expressions by allowing catch after the function.

My pitch is to allow catch to be declared after a throwing function with a preceding try? keyword to expose any resulting error.

Joakim Hassila asked two interesting questions about the Swift Concurrency threading model.

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:

  1. 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)
  2. Same goes for thread shutdown when no more work is around (so basically, how are the threads managed in the default executor)

Finally