[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