SE-0317: Async Let

Orup70 · 2021-06-12T15:25:14.249Z

toph42:

I’m a bit confused. There are possible suspend points in my code where there’s no await if I use async let ?

Yes, since the async let is creating a child task and the child task cannot outlive the parent scope.

If you ignore the result of the async let by not await:ing the result of the task, the task will automatically both be canceled and await:ed.

But, if I understand correctly, you will get a warning from the compiler about the unused (async) constant in the async let statement.

toph42 · 2021-06-12T16:23:47.507Z

So the only "hidden" suspend point is the end of the scope in which the async let was created? If so, that doesn't complicate reasoning about flow that much, as you are obviously in an async context anyway and whatever is calling your code expects it to be a suspend point overall.

I am imagining a situation where there's two execution paths and each path depends on a long-running async let value independent of the other, but the branch depends on a third long-running task's result. I'd want them to run concurrently to avoid unnecessary waits. Is the best thing then to start each path by cancelling the other path's task, so it has time to respond to the cancel (especially if these operations have expensive rollbacks required to cancel)?

Is there any way to get the Task.Handle from the variable to call cancel() on it explicitly, or is implicit cancellation the only way a Task created by an async let may be canceled?

Orup70 · 2021-06-12T22:42:59.981Z

toph42:

So the only "hidden" suspend point is the end of the scope in which the async let was created? If so, that doesn't complicate reasoning about flow that much , as you are obviously in an async context anyway and whatever is calling your code expects it to be a suspend point overall.

Another point of view would be, in the default scenario, there shouldn’t be any hidden suspension points in the code, since you really are expected to await any asynchronous value introduced by async let in the scope. The main reason for using async let is to retrieve or calculate a value asynchronously and not to first perform all that work, and then just throw the result away.

Failing to await could just as well have been treated as an error. But as I understand from the proposal, it’s allowed to give a greater flexibility at the cost of making the code a bit harder to reason about. Especially the first time you encounter this special case.

I did have to re-read the proposal(s) again to try understanding how explicit cancellation might work for async let. But I couldn’t find any indication that it’s possible. Maybe someone else knows?

The Task introduced by async let is hidden IIUC, and therefore you have no handle to invoke a cancel() method on. The only thing you can do is await to get the value (or not). But as in your example, I suppose you can often rely on the implicit cancellation if you just ignore await on one of the long running calculations. And actually check for the cancellation in the Task as well.

Otherwise I assume you have to use a task group or an unstructured Task to get an actual handle to call cancel() on.

toph42 · 2021-06-13T00:59:58.144Z

My imagined example is probably better suited to manually creating tasks that could then be managed than using async let for unmanaged child tasks.

Lantua · 2021-06-13T01:43:28.453Z

On the naming, I think it should parallel the async and/or asyncDetach blocks, whatever the name we decide on.

QuinceyMorris · 2021-06-13T04:26:57.264Z

Douglas_Gregor:

You need a new task if you're going to interleave computations, which async let creates.

It's taken a while to sink in, but this is the piece that I've misunderstood ever since the formal proposal appeared. This is actually a design goal, not a detail of how async let happens to be implemented right now.

I understand the coherence of this goal. It simplifies the conceptual model because every task has a single path of execution (that is, a single task can only have a single continuation "in flight" at any one time). That's simple to grasp and I have no problem with it as such.

However, I don't think this is the right model for async let. I think that async let (however spelled) is a foundational part of Swift concurrency. For developers new to Swift or new to concurrency, I think this is the second most basic concurrency-related syntax to learn, after the basic await syntax.

In other words, I think async let is going to be a concept to learn before learning about explicit child task APIs, and therefore it should read similarly to sequential code, without ceremony or additional syntax on the RHS of the =.

OTOH, I think that tasks should have ceremony and syntax, including at least a set of braces around the scope of each task. That's what is required for grouped child tasks, and for both kinds of unstructured tasks.

At this conceptual level, I don't think it matters (from a justification point of view) whether the async let task is concurrent or overlapped, or what kinds of thread-safety guarantees can be given. Those are downstream conceptual details.

What matters, I think, is that we're stuck with a dilemma, that async let shouldn't look like a task, but that it can't not look like a task in the current design.

s-k · 2021-06-13T05:04:29.431Z

toph42:

So the only "hidden" suspend point is the end of the scope in which the async let was created? If so, that doesn't complicate reasoning about flow that much , as you are obviously in an async context anyway and whatever is calling your code expects it to be a suspend point overall.

I agree if the end of the scope is the end of an async function. However, if the end of the scope is the end of an if block, one may very well overlook this potential suspension point.

Orup70:

But, if I understand correctly, you will get a warning from the compiler about the unused (async) constant in the async let statement.

I think there is currently no warning if the async let is awaited on in one path of execution (e.g. in an if) but not in others. Here, you have a potential suspension point without await and without a warning.

As I understand it, the currently proposed model is described in this post and refined in this post.

frameworklabs · 2021-06-13T07:03:39.119Z

That’s also my concern - we have structured concurrency but this structure is not really visible in the syntax - besides a little overloaded keyword…

Orup70 · 2021-06-13T07:10:28.682Z

s-k:

I agree if the end of the scope is the end of an async function. However, if the end of the scope is the end of an if block, one may very well overlook this potential suspension point.

When you start using async let it will probably be easy to miss that point. But I think it will feel more natural if you look at it as part of structured concurrency. If you declare and initialize a new variable in an if block, the variable will be deinitialized at the end of the block and you cannot use it after that scope.

The same applies to async let – any “asynchronous value” created with async let must be cleaned up at the end of the scope in a similar way. Either you await the value explicitly or the compiler/runtime will do it implicitly for you. Otherwise the Task would escape the scope.

I guess this is something we just have to learn. The potential suspension point is created by the actual async let statement. Any asynchronous work initiated by an async let statement will always be awaited for at the end of the scope (at the latest).

At the same time, I think we need to separate two use cases. The most common use case is when you initiate an asynchronous computation (parallel by default) with async let and you later await the result before using it. Simple and elegant, if you ask me. This is what you should teach a beginner.

But there is also the more advanced use case when you are only interested in the asynchronous value if some condition is fulfilled. E.g. in case you need to abort for some reason. Since the Task handle is hidden – which is the reason the async let feature is lightweight and simple to use – you cannot explicitly cancel the computation. At the same time, the structured nature requires it to be awaited before leaving the scope.

In this case the asynchronous value will be implicitly canceled and awaited for (automatically behind the scene). I don’t see any better way to handle this situation, except not allowing it in the first case. An unnecessary limitation, in my opinion.

s-k:

I think there is currently no warning if the async let is awaited on in one path of execution (e.g. in an if ) but not in others. Here, you have a potential suspension point without await and without a warning.

Ah, I haven’t tried that myself. But it makes sense if you think about it. Not awaiting the async let at all is either an error (a misunderstanding of the feature?) or you just haven’t finished the code yet. A warning is reasonable.

But if you have at least one path awaiting the async let you are most likely applying the “advanced use case” and want to discard the result of the async let in those other paths, to be implicitly canceled and awaited for. Otherwise you would have to explicitly await in every other path and still not use the result. This would, in most regards, be harder to understand and unnecessarily clutter the code than the implicit cancellation and awaiting.

But of course, it’s a trade off. Allowing the more advanced use cases makes it harder to understand where and when the code can potentially suspend.

JJJ · 2021-06-13T09:13:47.959Z

for element in list {
    async let x = f(element) // Should the compiler warn here?
    if maybe(element) { 
        element.y = try? await x
    }
    // Should the compiler warn here?
    // Or if x is not awaited above, should it just be implicitly awaited here?
    // Or should we require an `await continue` here??
}

I guess the author would probably want to spawn all the elements and only use the value of some, so this should really use a task group instead.

My question is if the compiler should

Warn about using async let in a loop
Warn about potentially un-awaited async lets in a loop
Require e.g. await continue
Somehow allow not waiting on a child task at the end of each pass through the loop
Just assume the author knows what (s)he is doing, and run all the f()s sequentially.

Edit: Updated with await continue.

Matthias · 2021-06-13T09:55:40.789Z

One other option may be to require an await on exiting a scope with a dangling async let. If the compiler identifies a branch where one or multiple async lets have not be awaited on it could offer to insert an await return, await throw (if the scope ends by throwing) or await break (this last one may be tricky). This wouldn’t force you to explicitly handle every single async let, but it would force you to mark the suspension point.

Now to me it doesn’t seem the most elegant and might just become something that we slap on the end of scopes to make the compiler happy. It also moves the needle back towards requiring await everywhere which the authors identified as a pain point when working with async let.

Final disclaimer: I have no experience in compiler work, so I do not know if this is in any way feasible or desirable.

michelf · 2021-06-13T14:26:36.100Z

I said previously that it's fine to have an implicit await at the end of the function, but I need to change/clarify that opinion: it's fine at the end of an async function because there's already an await from the caller at the call site, and we're sort of awaiting inside of that call boundary. But I think the await needs to be explicit at the end of a scope when in the middle of a function.

toph42 · 2021-06-14T00:54:14.454Z

This is my take as well, but it leaves the question of how to do it elegantly.

michelf · 2021-06-14T02:47:58.462Z

I guess we could have a simple standalone await:

func test() async {
   for n = 0 ..< 10 {
      async let x = work()
      async let y = work()
      if Bool.random() {
         await print(x + y)
      }
      await
   }
}

A standalone await statement would await all the async let declarations defined in the current scope. If needed the compiler will prompt you to add one.

But now we have a different problem: does it make sense for this standalone await, unlike the other awaits, to imply cancellation?

Jon_Shier · 2021-06-14T04:25:15.873Z

Inversely related to @toph42 and @michelf's concerns about implicitly awaiting cancellation at scope exit is the current inability to neatly await many async lets without caring about their results. This is especially true for async -> Void functions, but is generally true for any async function which has side effects you want without the value.

Say you have some async action functions returning Void. Sometimes you want to perform them individually, sometimes all at once, in parallel. In all cases you want them to complete. Currently, it's hard to express the await all functionality. async let _ is disallowed. Simply not awaiting the functions results in cancellation. Currently, we must explicitly name and await every value.

func performAll() async {
  async let x = x()
  async let y = y()
  async let z = z()
  _ = await (x, y, z)
}

Or perhaps we could allow async let _ when using @michelf's dangling await?

func performAll() async {
  async let _ = x()
  async let _ = y()
  async let _ = z()
  await
}

Or perhaps allow async let itself as a scope?

func performAll() async {
  await async let {
    x()
    y()
    z()
  }
}

Perhaps we could allow async let _ in a particular context?

func performAll() async {
  await {
    async let _ = x()
    async let _ = y()
    async let _ = z()
  }
}

Even better, perhaps we can drop the async let when we don't care about the values, and just add the await scope directly?

func performAll() async {
  await {
    x()
    y()
    z()
  }
}

I like the look of an await scope. I wonder if it's generally composable. What rules do we want in it? Perhaps its only new rule is the implicit async let nature of unawaited async results. Or perhaps that's too much.

Of course, we go the TaskGroup route and await separate references.

func performAll() async {
  await all(x, y, z)
}

func all<T>(_ actions: (() async -> T)...) async {
    await withTaskGroup(of: T.self) { group in
        for action in actions {
            group.async { await action() }
        }
    }
}

Except that won't work with parameters, barring more wrapping, at which point we've lost most of the convenience.

Perhaps this isn't that big of an issue. It just seems awkward to have a brand new feature that doesn't handle such a case very elegantly.

Lantua · 2021-06-14T09:25:09.456Z

One thing that worries me is that async let and TaskGroup has different behaviours if the program exits the scope with unused task(s).

TaskGroup cancels its (unused) child tasks if its body exits by throwing, while async let cancels the (unused) child task regardless.

I really think that such a difference will lead to inconsistent feelings when using API as a whole. Further, it turns into something you need to remember on an API-by-API basis, which isn't great.

I think it'd be better if async let behaviour is more similar to task group in this direction as well. After all, it is advertised as a "sugar, but also more optimized" version of the task group.

toph42 · 2021-06-14T11:27:56.523Z

michelf:

But now we have a different problem: does it make sense for this standalone await, unlike the other awaits, to imply cancellation?

Perhaps await cancellation is the correct spelling of explicitly awaiting cancellation of all the async tasks implicitly created in scope by async lets, and that could be required before exiting scope if an execution path tries to end with “dangling async let” declarations?

Jon_Shier:

Sometimes you want to perform them individually, sometimes all at once, in parallel. In all cases you want them to complete.

This is like my contrived example, I think: Just the wrong tool for the job. This is probably a job for TaskGroup.

Paul_Cantrell · 2021-06-14T14:13:58.825Z

Jon_Shier:

func performAll() async {
  async let x = x()
  async let y = y()
  async let z = z()
  _ = await (x, y, z)
}

Perhaps controversially, I don’t see the syntax above as being a bad thing. It makes it quite clear what’s happening — especially if we replace the variable names x, y, and z with meaningful descriptions:

_ = await (chargeBatteries, performPreflightChecklist, waveToCrowd)

Think about when we need this: as Jon points out, we’re only doing this because we care about some side effect before proceeding (or it should be a fire-and-forget Task { } instead). If we do care about a side effect, we’ll need to await to make sure that side effect actually completed before we proceed. Making that “side effect must be complete here” dependency apparent in the code seems important. And it seems likely that, as often as not, that will happen before the end of a local scope.

This doesn’t seem to me like a case that needs special sugar.

michelf:

But now we have a different problem: does it make sense for this standalone await, unlike the other awaits, to imply cancellation?

That certainly would be confusing.

Lantua:

One thing that worries me is that async let and TaskGroup has different behaviours if the program exits the scope with unused task(s).…It turns into something you need to remember on an API-by-API basis, which isn't great.

I think it'd be better if async let behaviour is more similar to task group in this direction as well. After all, it is advertised as a "sugar, but also more optimized" version of the task group.

Without commenting on the details of this particular problem, it does seem to me a compelling design principle that async let should, as much as possible, be simple sugar over TaskGroup — both in terminology and behavior.

Ben_Cohen · 2021-07-27T18:51:05.644Z

Review Conclusion

The proposal has been accepted.

Ben_Cohen · 2021-07-27T18:51:13.771Z