Issue #176 14 Jan 2021
Written by: Kristaps Grinbergs
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
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.
- 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
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.
Feedback was very positive on the concept of adding async/await in general with a few key points raised.
- It was suggested that
try awaitreads better than
await try. The core team agrees, and the proposal will be modified accordingly.
- There was some discussion of alternatives to
suspends) which may better describe the meaning. The core team feels that the benefit of sticking with
asyncas 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 letwill 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
await. The core team does not believe the current requirement to mark throwing calls with
tryshould 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
awaitto be sugared somehow (for example, some form of try block).
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
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:
- A standard library definition of a protocol that represents an asynchronous sequence of values
- Compiler support to use
for...insyntax on an asynchronous sequence of values
- A standard library implementation of commonly needed functions that operate on an asynchronous sequence of values
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
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.
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.
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
throwsin the future: if only enum errors are thrown the compiler could implicitly compose an error enum based on the call stack.
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.
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.