SE-0317: Async Let

[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.)