[Pitch #3] Async Let

[Douglas_Gregor]

@QuinceyMorris

After the pushback we’re seeing in this thread from @Douglas_Gregor and @ktoso, I’m trying to switch my point of view, to evaluate — and see if I can embrace — their apparently exclusively global-actor-based conceptualization of serial-execution contexts.

I don't understand what you mean by this last sentence.

@QuinceyMorris

I can’t find anything in the Actors proposal that’s very explicit about this, but I assume that dataFromNetwork — apart from its asynchronous portions, such as making a network request, that might run on an execution context outside the actor — will execute its synchronous portions and returns its result in MyActor’s execution context. Is that correct?

Yes. An actor-isolated function will run its synchronous portions in the actor's execution context. Now, we retain the right to optimize away the "hop" over to the actor's execution context if we can prove that the actor is unused within the synchronous portion, i.e., there's no references to "self".

@QuinceyMorris

Now let’s change doStuff like this:

	func doStuff() async {
		async let data = await dataFromNetwork()
		…
	}

This is fine. It's a concurrent task, but it'll end up serializing on the same actor until (e.g.) it ends up suspending while waiting for data to come across the network. This is a good description:

@JJJ

As far as I understand this, the system will just switch to the actor's execution context. You will only get a compilation error if you try to access non-Sendable data, as that is not safe to do from a different thread. I think the nonisolated part just tells you that this doesn't start out unconditionally "locking" the actor context.

@QuinceyMorris

I'm looking for confirmation of the behavior when the operation is asynchronous. In that case, some of the operation may go outside the actor, but the actor-related parts run in the actor context, I assume.

Yes, that's right.

@QuinceyMorris

Can we get confirmation that an isolated async function in an actor can be await ed "inside" the same actor instance in the obvious way? The Actors proposal seems to go out of its way to avoid mentioning this case.

Yes, you can call asynchronous actor functions from inside the actor. You'll still need to await them, of course, because they could suspend in their execution.

@QuinceyMorris

Can we get clarification about the behavior of async let when initialized to an isolated async function inside the same actor instance? The Async Let proposal seems to say explicitly that this won't even compile.

We can look to clarify the wording. The initializer of an async let is not isolated to the actor, but like any code outside the actor, it can interact asynchronously with the actor---it just needs to await its turn.

@Nickolas_Pohilets

unless the proposed async let somehow doesn't work with this as a future direction.

Currently I don't see an obvious way to extend async let to non-escaping futures in an additive way. The two are pretty different approaches. Do you have any ideas on how that might work?

One could imagine having async parameters of some sort, and allowing async let to be passed down to those:

func f(x: async Int) async { ... }

func g() async {
  async let y = doSomething()
  f(x: y)
}

The restrictions would have to be similar to inout, where we don't allow captures in non-escaping closures. It would be a lot of implementation work to make this happen, but I think it does fit.

Doug

[QuinceyMorris]

@Douglas_Gregor

The initializer of an async let is not isolated to the actor, but like any code outside the actor, it can interact asynchronously with the actor---it just needs to await its turn.

I'm uncertain at this point if this is the answer to my actual question. Here's the example again, it its async let variant:

actor MyActor {
	func dataFromNetwork() async -> Data { … }
	func doStuff() async {
		async let data = await dataFromNetwork()
		…
	}
}

The proposal says the initializer of the async let is equivalent to a closure that's "@Sendable and nonisolated". I read that as meaning this closure:

		{ return await self.dataFromNetwork() }

But surely self is invalid in a nonisolated closure?

[Douglas_Gregor]

@QuinceyMorris

The proposal says the initializer of the async let is equivalent to a closure that's "@Sendable and nonisolated". I read that as meaning this closure:

		{ return await self.dataFromNetwork() }

But surely self is invalid in a nonisolated closure?

Why would self be invalid in a nonisolated closure? self is captured, which is fine. Actor types are Sendable, because they handle their own synchronization.

• Doug

[Alejandro_Martinez]

Thanks this clarification makes a lot of sense. I think I was getting confused with so many names and different descriptions being thrown around.

I also think the names make a lot of sense when you understand structured concurrency. Which is a key part of the conversation. We need to somewhat forget about what we are used to with other systems like promises because this is not that.

Quite happy with the pitch. +1!

[tourultimate]

I like the proposal and the async let spelling.

[freda]

The proposal has this code:

func makeDinner() async throws -> Meal {
  async let veggies = chopVegetables()
  async let meat = marinateMeat()
  async let oven = preheatOven(temperature: 350)

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

and I would like to ask a question about the location of that try that I marked.

For me this location seems to be not intuitive. I now have to remember at this location that veggies is produced by a throwing function.

To me the following code would feel much more natural:

func makeDinner() async throws -> Meal {
  async let veggies = try chopVegetables()
  //                  ^^^
  async let meat = marinateMeat()
  async let oven = preheatOven(temperature: 350)

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

What is the reaon that the try is not matched to the throw and we have to remember this at the time of usage.

I am assuming that the try on the last line is because the method cook is throwing.

[freda]

One additional question about the await on the Dish line. This is just for clarification.
suppose that there is an additional ingredient that is not async.

let additionalIngredient = getFromStock()

If I then create the Dish what would the syntax be:

let dish = Dish(ingredients: await [veggies, meat, additionalIngredient])

or

let dish = Dish(ingredients: [await veggies, await meat, additionalIngredient])

or could I even do

let dish = await Dish(ingredients: [veggies, await meat, additionalIngredient])

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

@freda

suppose that there is an additional ingredient that is not async.

Any of those syntaxes is fine:

async let one = ... 
async let two = ... 
let not = ...

Dish([await one, await two, not])
Dish(await [one, two, not])
await Dish([one, two, not])

Generally the rule is currently the same as with try wrt if an expression is "covered" with an await.

[freda]

Thanks

[frameworklabs]

Then maybe write it like this:

func makeDinner() async throws -> Meal {
  let (veggies, met, oven, _) = try parallel {
    try run { chopVegetables() }
    run { marinateMeat() }
    run { preheatOven(temperature: 350) }
  }

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

[malhal (Malcolm Hall)]

The async let and closures code sample in the proposal is failing for me with Capturing 'async let' variables is not supported which I thought was strange given the * Status: Implemented (Swift 5.5)