SE-0317: Async Let

[jazzbox (Bernd Ohr)]

I already know that!!!

I haven't tried a preview of Swift and therefore I don't know what the type of an async let is, but for a moment, as a thought experiment, let's assume that it is just like a partial application. To get the value only a simple () would be sufficient, no need for an await, it is implicit:

func g() async throws -> Int { ... }

async let g1 = g() // assumed type: g1: () throws -> Int

print(try g1()) // no await necessary here

[kiel (Kiel Gillard)]

@Chris_Lattner3

  @ThrowingFuture let veggies = { try await chopVegetables() }
  @Future let meat = { await marinateMeat() }
  @Future let oven = { await preheatOven(temperature: 350) }

  let dish = Dish(ingredients: await [try veggies, meat])
  return try await oven.cook(dish, duration: .hours(3))

If I am understanding this approach and all the concurrency proposals correctly (I'd be surprised!), one thing I like about this approach is the potential API design it might unlock.

For one, could a developer treat the property wrapper like a task handle and do things like cancel tasks? e.g.:

@Future let meat = { await marinateMeat() }

// ...later:
$meat.cancel()

if $meat.isCancelled {

If that is a possibility, perhaps group wrappers could be introduced, generic over the result, where the task group be passed into the closure? e.g.:

@GroupingFuture<CookingTask> let cookingTask = { group in
    // spawn three cooking tasks and execute them in parallel:
    group.async {
      CookingTask.veggies(try await chopVegetables())
    }
    group.async {
      CookingTask.meat(await marinateMeat())
    }
    group.async {
      CookingTask.oven(await preheatOven(temperature: 350))
    }
}

// later, cancel this group of tasks
$cookingTask.cancel()

[michelf (Michel Fortin)]

@ktoso

Proposal: disallow un-used async let declarations

There is one simple rule that can solve both of these problems: all async-let bindings must be used at least once. This rule is equivalent to "unused variable" detection in present day Swift, but should be escalated as an error for async let bindings.

I agree with this, except it should be a warning IMO. The reason is if you temporarily comment a block of code later in the function you probably don't want the async let above to become a hard error. Or if you are writing the function, it'd be a bit harsh for Xcode to show an error as soon as you've written the async let line.

async let _ could be an error though.

[masters3d]

@Chris_Lattner3

• By using closure syntax, we more clearly delineate that the initializer expressions are not part of the enclosing scope. This matters because they do/should introduce a @Sendable check, they should change the behavior of actor self to require an sync jump, and will have other effects. This is load bearing syntax, not boilerplate.
• By making the closure explicit, it means that we can bring back the try and await modifiers in the initializer list and it makes sense what they mean and they are now consistent with the rest of the language.
• The use of closure syntax allows us to use multi-statement computation of the value, not just a single inline expression. This is more powerful.

I agree on the above. The autoclosure semantics currently proposed should be explicit regarles of how we resolve the left side of the expression.

this is more of a future/promise so we should either call it that or something close to that. async is too overloaded.

[Paul_Cantrell]

@Chris_Lattner3

@kavon

There's also the problem that the word "async" in an async let does not mean the same thing as the effects specifier async on a function type. An async let creates a new task to run the code on the right-side of the equals, but a new task is not created when calling an async function. So, I think it would be a mistake to write throws , which is also an effect, next to that async .

I completely agree with this observation, this is muddying the meaning of the word async , blending in a different meaning than the effect modifier. This is not creating an "asynchronous let" - that doesn't even make sense, constants are not asynchronous! This is creating a future let or deferred let or something like that. In fact, we're creating something much closer to:

let x : Future<_>

If the design goal was to tie this to effect modifiers, then we should also be discussing adding try let x = someThrowingThing() for deferred error checks.

This whole dual meaning of async continues to bother me across all these proposals. These proposals use that same word for both:

1. indicating the presence of an effect and
2. creating a context that handles that effect.

This creates confusion for programmers around the crucial question of “Am I introducing concurrency, handling it, or indicating that my code here requires that the calling code handle it?” The word async can mean all these things.

As an analogy, consider what Swift would look like if we did the same thing for error handling, using the same word for both the effect and the context that handles it:

func createWidget(name: String) error -> Widget { ... }

let foo = error createWidget(name: "foo")

…or worse yet:

extension Array {
  init(count: Int, generator: () error -> Element) reerror {
    self = error (0..<count).map { _ in
      error generator()
    }
  }
}

let widgets = error! Array(count: 10) {
  error createWidget(name: "blarg")
}

What code above potentially causes an error? What code handles the error? It takes some head-scratching to figure out. The word “error” is scattered everywhere, meaning multiple things.

Code in the current proposals suffers to my eye from a similar problem: the word “async” is scattered everywhere, meaning multiple things.

We solve this problem by using completely separate words for the presence of the effect (throws) and creating a context for handling the effect (try):

extension Array {
  init(count: Int, generator: () throws -> Element) rethrows {
    self = try (0..<count).map { _ in
      try generator()
    }
  }
}

let widgets = try! Array(count: 10) {
  try createWidget(name: "blarg")
}

I wonder if it’s not too late to think hard about this, while we still have the chance. It does seem to me to be a significant part of the problem @kavon and @Chris_Lattner3 note above.

I do note that the Structured Concurrency proposal is moving partially away from async { … }, renaming standalone task creation to Task { … } (though that proposal does still have group.async).

[michelf (Michel Fortin)]

@Chris_Lattner3

  @ThrowingFuture let veggies = { try await chopVegetables() }
  @Future let meat = { await marinateMeat() }
  @Future let oven = { await preheatOven(temperature: 350) }

  let dish = Dish(ingredients: await [try veggies, meat])
  return try await oven.cook(dish, duration: .hours(3))

We already have a future though. It's called Task. Perhaps Task could also be a property wrapper:

@Task let meat = { await marinateMeat() }

That'd not have the same behavior as async let though (not cancelling or awaiting when going out of scope). So we sort of need another kind of future with some @_magic behavior:

@ScopedTask let meat = { await marinateMeat() }

I still wish the task would be cancelled as soon as the control flow determines its result won't be used, and awaited at the end of scope, but that's likely impossible with this design. It could offer an explicit $meat.cancel() though, which in some way is better.

---

It'd be nice if there was no need to have two kinds of future (Task and ScopedTask). Is there no way to align the behavior of the two so there is only one kind of future?

[BigSur ({ @MainActor  in M1.Ultra }(Swift))]

@michelf

It'd be nice if there was no need to have two kinds of future ( Task and ScopedTask ). Is there no way to align the behavior of the two so there is only one kind of future?

I'm not supportive of @magic approach, but Task.scoped{} Task{} Task.detached{} could align well with each other, TaskGroup.async{} looks inconsistent with Task-style concurrency primitive api.

[Jon_Shier]

@Paul_Cantrell

This whole dual meaning of async continues to bother me across all these proposals. These proposals use that same word for both:

1. indicating the presence of an effect and
2. creating a context that handles that effect.

This doesn't seem to be correct. The async on async let is not a signifier like await or try, it's still an effect, it's just an effect on the declaration rather than a function. In that regard I don't find it a misuse at all. In fact, the symmetry between the various uses of async make the feature rather easy to learn, rather than requiring new vocabulary for every slightly different use.

[Paul_Cantrell]

As a friend points out off-forum, my analogy to throws / try is broken: strictly speaking, await is the effects handler for async, and it already has a separate name. And the analogy further breaks down there: try eats the effect in question, whereas await propagates it upward.

My whole post, then, only stands as a qualitative analogy about the danger of overloading a term too much, not as a strict isomorphism between asynchronous code and error handling.

What’s really bothering me, then? Kavon said it succinctly:

@kavon

The word "async" in an async let does not mean the same thing as the effects specifier async on a function type. An async let creates a new task to run the code on the right-side of the equals, but a new task is not created when calling an async function.

As I understand the proposals at hand, we currently have this situation:

		Creates a task	Introduces async effect
(1)	async on a declaration
(2)	async let		later in enclosing scope
(3)	group.async		later in enclosing scope
(4)	Task { … }		only if getting result
(5)	Task.detached { … }		only if getting result

In previous proposals where (4) was named async { … }, the meaning of “async” got really confusing. Now, IIUC, Task and Task.detached (and other functions that call them) are the only things that can create tasks without introducing the async effect into their enclosing scope, and are thus are the only bridge from non-async code into async code. Is that correct? If so, then we can at least say that async, whatever else it means, always indicates the presence of an effect somewhere in the current scope…though not always right at the point of use. Thus 1-3 must propagate up through the call chain until they hit 4-5. That’s clearer, at least.

What’s still bugging me is that we are using the same word for both 1 and 2-3. Does “async” create a new task or not? In particular, it muddies two things that should be clear:

1. It should be clear that foo() async does not in fact create a child task when called. (Prior experience with Javascript et al should not be a prerequisite for understanding this.)
2. It should be clear that 2-3 introduce task boundaries, as Chris wrote above:

   @Chris_Lattner3

   the delineation between the "body" of the task being created and the enclosing function is not clear. … This matters a lot because you have @Sendable checks, actor self behavior changes and other things that happen at task boundaries. This needs to be visible in the Swift code IMO.

I’m not sure I love either the syntax particulars or the word “future” here:

@Chris_Lattner3

  @ThrowingFuture let veggies = { try await chopVegetables() }
  @Future let meat = { await marinateMeat() }
  @Future let oven = { await preheatOven(temperature: 350) }

…but this general line of thinking does potentially address my concern.

[Paul_Cantrell]

@kiel

If I am understanding this approach and all the concurrency proposals correctly (I'd be surprised!), one thing I like about this approach is the potential API design it might unlock.

For one, could a developer treat the property wrapper like a task handle and do things like cancel tasks? e.g.:

@Future let meat = { await marinateMeat() }

// ...later:
$meat.cancel()

This is interesting! It potentially addresses two concerns I had in the pitch phase:

1. Passing async lets as futures/promises

@Paul_Cantrell

unlike Task.Handles and futures that it is not possible to pass a "still being computed" value to another function

In general, this makes sense under the structured concurrency model. I wonder, however whether it precludes too many common basic refactoring patterns (e.g. splitting a long method into shorter ones). Might it be possible to allow “passing a handle” to direct function calls, and allow non-escaping closures to capture them?

The answer might look like this:

@Future let thinger = { ... }
someHelper($thinger)  // passes a future; someHelper won’t block on thinger
                      // unless it needs the value

func someHelper(_ thinger: Future<Thinger>) { ... }

2. Mixing “async lets” with manually created child tasks

@Paul_Cantrell

Is there a missing bridge between the world of async let and the world of manually created task groups?

Suppose for example that we want to execute heterogenous tasks and there is an arbitrary number of one of those tasks. Taking the makeDinner() example from the proposal, suppose there are veggieCount vegetables instead of exactly one, and we want to chop them all concurrently. … What if we want to keep using async let for meat and oven while supporting the arbitrary number of veggies?

Here’s a start of a solution to that:

return try await withThrowingTaskGroup(of: ??????????) { group in
  for n in 0..<veggieCount {
      group.async {
        CookingTask.veggies(try await chopVegetables(n))
      }
  }
  @Future(group: group) let meat = { await marinateMeat() }  // tying async/future variable to a specific group
  @Future(group: group) let oven = { await preheatOven() }

  // …but wait, how do we get the veggies out?
  // What is the result type of this task group? Hmmmmm.
}

So not a solution, not quite, but at least a design space for one.

(Not proposing discussion of either of these; just saying that the property wrapper approach opens up future directions in a nice way.)

[Syre]

@Chris_Lattner3

A more general discussion we should have is "what is the Result equivalent for async and what is it called". We need that type, and having it would make this sugar feature much easier to reason about. This concept is commonly called a "Future" or "Promise" in existing systems.

Ok thank you for clarifying, I guess the concern I was trying to raise is that I thought at least part of the async/await design was distinctly that you would never have to think about a Future/Promise.

func marinateMeat() async -> Meat
func marinateMeat() -> Future<Meat>

Afaict this is two nearly identical spellings for the same exact thing. Generally speaking that's not a bad thing imo ([T] being equivalent to Array<T> is a significant shorthand that most would agree improves usability of arrays), but in this particular case, I personally am not sure how async -> T is a significant usability improvement over -> Future<T> or vice versa.

This is why the suggestion to have Future and async is so confusing to me. Basically I'm asking "why do we need both?"

[Chris_Lattner3 (Chris Lattner)]

@michelf

We already have a future though. It's called Task . Perhaps Task could also be a property wrapper:

@Task let meat = { await marinateMeat() }

This isn't quite right outside the narrow case covered by this proposal.

Tasks and the values produced by them are different in important ways. This proposal doesn't cover it, but you can have a single task that yields multiple values over time (generator style) and binds them as it goes. It is also fine to return multiple values that resolve at different times. For example, to put this into fictional syntax terms, it is perfectly fine to have something like:

func x() -> (Future<Int>, Future<String>)

Where there is a single task completes each future at different times.

This proposal doesn't provide support for these advanced cases, but I don't think that conflating these together in the broader lexicon of concurrency is a good way to go.

-Chris

[Joe_Groff]

We should emphasize that being able to pass off a future for a child task is an anti-feature. Allowing handles to a child task to escape the scope of their parent task would break the guarantee we want to make about child tasks, that their lifetimes are always bounded by a scope, and they stop executing and consuming any resources after that scope is ended. It could be interesting and useful to turn the Task handle for unstructured/detached tasks into a property wrapper—that could definitely reduce the Hamming distance between async let and unstructured concurrency when you find your use case has grown beyond the abilities of structured tasks, but your tasks are still "mostly" structured—but, by itself, async let shouldn't be thought of as sugar over futures, but as sugar over simple task groups. To that end, I think the syntax is justified, because it addresses ergonomic and readability issues with task groups that are classes of things we've historically taken efforts to improve:

• Generalized task groups require introducing at least one layer of indentation for the withTaskGroup { } block. Although this is necessary in their full generality, since if you want to conditionally add work to a group in an if block or loop, we need a task group scope that's independent of any single statement scope, there are many cases where the set of child tasks is fixed, and the desired scope for the child tasks match the scope of a block statement that already exists in the code. Many times in Swift's evolution, we've taken pride in tearing down "pyramids of doom", and although one extra indentation is less of a Giza and more of a Bass Pro Shop pyramid, I think saving the indentation is still worth it.
• Task groups in their full generality also need to allow for 0, 1, or N child tasks, and so their primary interface for consuming child task results is as an AsyncSequence. However, in the same category of cases where you have a known number of child tasks, each with known result types, the homogeneous, indefinite-length nature of an AsyncSequence is suboptimal. You're forced either to force-unwrap the Optional result of next() to get the value of a single child task, or set up a local enum type to manage heterogeneous results from multiple child tasks, and then assert that you've seen one of every enum payload by the time you've iterated through all the child tasks. Not only is that a lot of boilerplate, but in Swift, we generally like language features that let your code be correct by construction, relying on trapping runtime assertions only as a last resort.

[kavon (Kavon Farvardin)]

@Paul_Cantrell

  // …but wait, how do we get the veggies out?
  // What is the result type of this task group? Hmmmmm.

This isn't 100% related to async-let, but I wanted to answer your question here: you can loop through the values returned by tasks within a group using for-await:

return try await withThrowingTaskGroup(of: Veggie.self) { group in
  for i in 0..<veggieCount {
      group.async {
        try await chopVegetable(i) // returns value of type Veggie
      }
  }
  async let meat = marinateMeat()
  async let oven = preheatOven()

  for try await veggie in group {
    // do something with veggie
  }
  await oven // .. do something with oven ..
}

Async-let is already designed to work within a task group's block (or vice versa). If you want to have a heterogenous type returned for the group, you can change the type passed to the of argument label to be an enum that accounts for the various cases. Alternatively, just use async-let in the group, like I wrote above.

[Paul_Cantrell]

@kavon

This isn't 100% related to async-let, but I wanted to answer your question here: you can loop through the values returned by tasks within a group using for-await:

return try await withThrowingTaskGroup(of: Veggie.self) { group in
  …
  for try await veggie in group {
    // do something with veggie
  }
  await oven // .. do something with oven ..
}

If the subtask that yields oven is a direct member of group itself (as opposed to a child task), then that approach can only work if oven is a Veggie. Thus my “but wait” comment in the code.

(And yes, the heterogenous results enum approach of the original example from the structured concurrency proposal addresses this, but it would certainly seem odd if the type passed to withTaskGroup constrained every async let inside it!)

I assume, then, that when you write:

Async-let is already designed to work within a task group's block (or vice versa).

…that means async let must create a child task of the task group?

Perhaps that is always sufficient! It’s not clear to me whether there’s ever an important difference between the “heterogenous results enum” approach and the “separate child tasks” approach. I’d just originally wondered whether the pitch paints us into a design corner around that question; knowing that there’s a path to address it should it ever matter would give me confidence to ignore it entirely for now. An escaping design-space future, if you will.

[kavon (Kavon Farvardin)]

@Paul_Cantrell

If the subtask that yields oven is a direct member of group itself (as opposed to a child task), then that approach can only work if oven is a Veggie . Thus my “but wait” comment in the code.

The async-let task is not a member of the task group. It's just scoped to the same block/closure that group is.

@Paul_Cantrell

Async-let is already designed to work within a task group's block (or vice versa).

…that means async let must create a child task of the task group?

No. The task-group object creates tasks that are subtasks of the task that calls group.async. The lifetime of those tasks is limited to the block in which group is defined, because exiting that block implicitly awaits the tasks in the group. Otherwise, you can write arbitrary code in that block, such as async-lets or ordinary let's.

If you define an async let at the top level of that group's block, then its lifetime also happens to be limited to the block in which the group is defined, just like any other let-binding appearing in that block. Because those tasks are tied to an async-let, they'll be cancelled and awaited when going out of scope.

[Paul_Cantrell]

@kavon

No. The task-group object creates tasks that are subtasks of the task that calls group.async . The lifetime of those tasks is limited to the block in which group is defined, because exiting that block implicitly awaits the tasks in the group . Otherwise, you can write arbitrary code in that block, such as async-lets or ordinary let's.

Ah! I see. Not what I expected, but it makes sense. Thanks for taking the time to explain!

This implementation approach further suggests there’s really no particular need to be able to assign an async let to one specific group, and I’m just fretting over hypothetical nothings.

[critz (Michael Critz)]

On the subject of try I find that nearly all asynchronous action is subject to failure: databases, filesystems, networks, long computations, etc.

I’d prefer calling async imply failure rather than set myself up for a career future where nearly all async requires extra boilerplate.

[toph42 (Topher Hickman)]

Does this feature allow for optional binding? Can you if async let?

[ktoso (Konrad 'ktoso' Malawski 🐟🏴‍☠️)]

No, because to fulfill that you’d have to actually get the value out of it — so it can’t “just” async but must also await. In which case, it becomes just if let x = await.

(Same goes for guard)