We are back from the holiday break. Whether you celebrate or not, I hope you took some time off to relax after this crazy 2020. We’re now in 2021, and I believe this year we will slowly move back to a more normal life. I hope we can meet in smaller meetups at the end of the year and start to safely travel again.

We have significant updates from async/await field. A proposal adding this functionality has been accepted! There is a great video by Vincent Pradeilles demonstrating how we can experiment with it already using the Swift development snapshot. Check it out.

I want to end this issue by calling for sponsors. Swift Weekly is a great place to promote your solution or company and target the Swift language professional audience. You’d also be supporting a community-backed project. This email and website would not be possible without our sponsors. We need to cover running costs and have some exciting plans to bring this project to the next level. Financial support would go a long way towards achieving these goals.

Interested in sponsoring Swift Weekly Brief? Learn more here.

Starter tasks

  • SR-13976 [Compiler] Improve compiler error message: “partial application of ‘mutating’ method is not allowed”
  • SR-14015 [Docs] Update references master -> main for branch related information

Podcasts

In Empower Apps #74, Leo Dion and Tim Condon talk about the Swift Server Work Group, SwiftNIO, Server-Side Swift’s growth in 2020 and Swift on Server-Side ARM.

News and community

The founder of this newsletter, Jesse Squires, wrote a post exploring the type of self in a Swift self-executing anonymous closure used to initialize a stored property. Nolan Waite pointed out that this bug is being tracked at SR-4559 and SR-4865.

Kilo Loco shared a tool called Swift Lambda Maker. Swift Lambda Maker is a CLI tool used to create and package AWS Lambda functions written in Swift. It can create a new executable Swift Package where you can start coding your Lambda as well as package that Lambda as a zipped Docker image.

Great blog post about updates from SwiftWasm team.

Accepted proposals

SE-0296: Async/await was accepted.

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

  • It was suggested that try await reads better than await try. The core team agrees, and the proposal will be modified accordingly.
  • There was some discussion of alternatives to async (such as suspends) which may better describe the meaning. The core team feels that the benefit of sticking with async as a term of art with precedent in many other languages was preferable to the the slight descriptive benefit of alternative names. Note that other uses of async such as async let will be considered in other proposals.
  • Several reviewers expressed concern that it was hard to review this proposal “stand alone”, since it interacts so closely with, and its use depends on, other yet-to-be-reviewed proposals. The core team acknowledges this, but feels that this is unavoidable given the large surface area of the whole concurrency feature. To mitigate this, reviewers of subsequent proposals should feel free to revisit parts of accepted concurrency proposals in reviewing those subsequent proposals when they interact.
  • Several reviewers were disappointed about subsetting out getters. The core team wants to be clear that this is just left as a future direction, not ruled out, and as such isn’t a reason to hold back on accepting this proposal.
  • In a separate thread to the review, there was some discussion of the necessity of try and await. The core team does not believe the current requirement to mark throwing calls with try should be revisited, and thinks there is a similar need to mark possible suspension points with await. The core team would be open to considering future proposals that allow multiple calls needing either try or await to be sugared somehow (for example, some form of try block).

Rejected proposals

SE-0292 has been returned for revision.

The feedback to the idea of defining an open-standard Package Registry HTTP based API, and implementing support for it in SwiftPM as an alternative to resolving dependencies via git, was very positive.

Proposals in review

SE-0290: Unavailability Condition is under a second review.

The second review of SE-0290, “Unavailability Condition”, begins now and runs through January 12, 2021. This proposal was previously returned for revision 1.

SE-0298: Async/Await: Sequences is under a review.

Swift’s async/await feature provides an intuitive, built-in way to write and use functions that return a single value at some future point in time. We propose building on top of this feature to create an intuitive, built-in way to write and use functions that return many values over time.

This proposal is composed of the following pieces:

  1. A standard library definition of a protocol that represents an asynchronous sequence of values
  2. Compiler support to use for...in syntax on an asynchronous sequence of values
  3. A standard library implementation of commonly needed functions that operate on an asynchronous sequence of values

Swift Forums

Tom Doron informed us about development for Swift 5.3.3 for Linux and Windows.

We are happy to announce the opening of the development phase for Swift 5.3.3 for Linux and Windows.

  • Merge window open: 17th December 2020 (now)
  • Merge window close: 22nd January 2021
  • Planned release: End of January or February 2021

James Sherlock pitched to add support for repositories which contain multiple packages for the first time.

Many developers operate under a “mono repo” design pattern where code for multiple packages or projects exists under one repository.

Swift Package Manager currently assumes that each repository only contains one package, this may not always be true - this proposal aims to add support for repositories which contain multiple packages.

Mattt started a discussion about URLs as Swift package identifiers.

We believe that using URLs as package identifiers is intuitive and familiar for developers, and will best solve the immediate and future needs of this project.

Doug Gregor posted an update describing the Structured Concurrency Pitch Document revisions.

Jeff Kelley pitched an idea to add sugar for preconditions and guards.

Chuquimia_Max expressed an idea to add enum composition.

It seems this has almost been discussed here and here but never with what I would consider to be an intuitive, Swift-esque syntax.

Essentially, I reckon it would be beneficial to be able to create a composed enum using & in the same way protocol composition is currently functioning. Composable enums could also be handy if we get typed throws in the future: if only enum errors are thrown the compiler could implicitly compose an error enum based on the call stack.

Joe Groff pitched an idea about continuations for interfacing async tasks with synchronous code.

Asynchronous Swift code needs to be able to work with existing synchronous code that uses techniques such as completion callbacks and delegate methods to respond to events. Asynchronous tasks can suspend themselves on continuations which synchronous code can then capture and invoke to resume the task in response to an event.

Mishal Shah informs us that Swift 5.4 nightly development snapshots are now available on https://swift.org/download/#snapshots.

Ted Kremenek updated the community concerning new changes to the Code of Conduct.

We all want the Swift community to be welcoming and inclusive, and a place where anyone can come to answer questions, propose their ideas, and help shape the future of Swift. To better promote inclusiveness, the Core team is revising the Code of Conduct on Swift.org that covers all aspects of the Swift project.

The revision incorporates changes from v1.4 of the Contributor Covenant, which provides examples of positive behaviors and suggestions for us all to keep in mind in our interactions. The revision also clarifies some policies to follow when issues arise.

Finally

The iOS Developer Community Survey 2020.