Async let created tasks

[robert.ryan]

@EndBird

What I am confused about is how is async let the same as a Task Group?

Both async let and task groups are structured concurrency, notably enjoying automatic propagation of cancellation. See SE-0317, which says:

@SE-0317 – Introduction

Structured concurrency provides a paradigm for spawning concurrent child tasks in scoped task groups, establishing a well-defined hierarchy of tasks which allows for cancellation, error propagation, priority management, and other tricky details of concurrency management to be handled transparently.

This [async let] proposal aims to make the common task of spawning child tasks to run asynchronously and pass their eventual results up to their parent, using lightweight syntax similar to let bindings.

Later it says:

@SE-0317 – Comparing with TaskGroup

Semantically, one might think of a async let as sugar for manually using a task group, spawning a single task within it and collecting the result from group.next() wherever the async let declared value is await-ed on. As we saw in the Motivation section of the proposal, such explicit usage of groups ends up very verbose and error prone in practice, thus the need for a "sugar" for the specific pattern.

A async let declaration, in reality, is not just a plain sugar-syntax for task groups, and can make use of additional known-at-compile-time structure of the declared tasks. For example, it is possible to avoid heap allocations for small enough async let child tasks, avoid queues and other mechanisms which a task group must make use of to implement its "by completion order" yielding of values out of next().

You go on to ask:

@EndBird

Doesn’t async let just create one task so it’s like calling a Task rather than Task Group?

In contrast to async let, Task {…} is unstructured concurrency, meaning, amongst other things, you do not enjoy automatic cancellation propagation. And if you want to enjoy cancellation propagation with unstructured concurrency, you have to manually do this yourself with, for example, withTaskCancellationHandler.

Furthermore, if you create a Task {…} (unstructured concurrency) and do not explicitly await it, it will continue to run even after it falls out of scope. If you want to cancel it later, you have to save the reference to the Task somewhere and manually cancel it yourself.

With async let, however, you enjoy automatic cancellation propagation. Also, if you let it fall out of scope and neglect to await it, its task will be immediately cancelled (and, coincidentally, implicitly await that task to respond to the cancellation). See SE-0317 – Implicit async let awaiting.

@SE-0317 – Implicit `async let` awaiting

A async let that was declared but never awaited on explicitly , as the scope in which it was declared exits, will be awaited on implicitly. These semantics are put in place to uphold the Structured Concurrency guarantees provided by async let .

Finally, you asked:

@EndBird

To be clear, when people talk about the async let feature, do they mean the whole async let + the await at the end or just the async let declaration?

In practice, they’re generally talking about async let that you will eventually await.

There generally is little point in ever doing async let without an explicit await because if it falls out of scope before you await, it will be immediately cancelled (unlike Task {…}), as I discussed above. That having been said, we consciously leverage this at times, e.g., for early-exit scenarios, where this simplifies our code not having to manually cancel tasks that we no longer need.

But, unlike structured concurrency, when you use async let, you always await, generally with an explicit await, and occasionally relying on the implicit cancel/await logic.