I first published this article on appcoda.com
The goal: readable asynchronous/parallel code
In designing the
await construct, Apple is hoping to increase the readability, and thus maintainability, of implementing concurrency/parallelism in Swift. What I see in it are attempts:
- to make asynchronous/parallel code almost look like synchronous/sequential code; and,
- to make asynchronous/parallel code much more semantically clear (more readable, less verbose, compact, doing what it says).
These are laudable and ambitious goals, but I’d say Apple’s heading in the right direction. I’m glad because I write a lot of asynchronous code to keep my apps responsive — to create the best possible user experience for my customers. I have a feeling that most of you write a lot of concurrent code, too.
We’ll walk through how to use
await in detail, but I will limit my discussion to it. You need to understand
await before trying to use Swift’s other new concurrency features, like actors, continuations, the
AsyncSequence protocol, the
TaskGroup generic structure, task cancellation, and a few other concepts.