The previous issue has a more extensive introduction, so for this one I’ll keep it short. WWDC is coming up really soon — I’m very much looking forward to it and seeing/meeting people online. Come say hi if possible :-)

Interested in sponsoring Swift Weekly Brief? Learn more here.

News and community

Tom Doron wrote a blog post and announced Swift AWS Lambda Runtime, designed to help Swift developers build serverless functions for the Amazon Web Services Lambda platform.

Fabian Fett wrote a blog post on getting started with Swift on AWS Lambda.

Daniel Dunbar announced llbuild2, an experimental, Swift native, fully async, NIO futures-based low level build system. Started as the cevobuild experiment in llbuild, it aims to continue that exploration.

Ben Cohen played around with Collection, implementing an EitherCollection that is a whopping 774x faster than AnyCollection.

Jasdev Singh posted a video on “Deriving Publisher from Swift’s Sequence protocol”.

Johannes Weiss wrote about “Looping” over Futures:

We’ve got a “rule of three” so when we get asked the same question three times, we need to do something to document it and today was at least the third time I personally got asked the “looping over futures” question.

I love this rule.

Commits and pull requests

Doug Gregor opened a pull request for multi-statement closure type inference. The supported statements are currently limited, but will improve over time. 🏎

Proposals in review

SE-0282: Interoperability with the C Atomic Operations Library ⚛︎ is under a second review.

This proposal adopts a C/C++-style weak concurrency memory model in Swift, describing how Swift code interoperates with concurrency primitives imported from C.

This enables intrepid library authors to start building concurrency constructs in (mostly) pure Swift.

This proposal includes a proof-of-concept package demonstrating the use of atomics from C to provide a low-level atomic API to Swift.

Swift Forums

Mattt pitched a proposal for a Swift package registry service.

Swift Package Manager downloads dependencies using Git. Our proposal defines a standard web service interface that it can use to also download dependencies from package registries.

Today, a package dependency is specified by a URL for a Git repository. When a project is built for the first time, Swift Package Manager clones the repository for each dependency and attempts to resolve the version requirements with the available tags.

Patrick Weigel pitched a proposal to replace the reference types weak and unowned with nonstrong.

In Swift it is possible to create strong reference cycles between class instances. Strong reference cycles are bad as they create potentially crashing memory leaks (unused memory that is not made available to the app). Swift provides two ways to resolve strong reference cycles: weak references and unowned references. Swift requires the coder to determine which type (weak or unowned) to use, when in many instances the coder simply wants the type to be not strong.

Dave Abrahams pitched a proposal to allow non-public conformances to implement public API.

In Swift, protocol extensions provide a beautiful way to share API implementations across value types. For example, an extension on the Equatable protocol provides a public implementation of the != operator to all public conforming types. The power of this feature is limited, however, because the conformance can never be less visible than APIs provided by extensions depending on that conformance.

Denys Shabalin pitched a proposal for Automatic Requirement Satisfaction in plain Swift.

Swift can automatically generate code to satisfy the requirements of special protocols such as Equatable, Hashable and Codable. For example, any struct whose stored properties conform to Equatable can itself conform simply by declaring it so, without explicitly implementing Equatable’s requirement for a static func ==(Self, Self) -> Bool:

struct Point: Equatable { 
    var x: Float
    var y: Float
}

The implementation of == for Point is synthesized by the compiler behind the scenes.

This functionality is extremely convenient, but it is currently limited to the few protocols for which the compiler defines automatic requirement satisfaction. We would like to lift this restriction and allow for arbitrary libraries to vend protocols and automatic conformances.

Dave Abrahams pitched a proposal for an Implementation Model for Rational Protocol Conformance Behavior.

When Swift implementers are faced with questions about the intended programming model for generics, they commonly respond with a focus on how generics are implemented, which, as the latter discussion shows, is not always compatible with the intended semantics. Furthermore, it makes a poor foundation for user (and especially my) understanding.

Tom Doron shared the Swift on the Server, May 13th work group updates.

Finally

No link in this issue. You are awesome. Stay safe out there. ❤️