[Pitch #3] Async Let

[Douglas_Gregor]

@adamkemp

What happens when I change this code:

// func doOtherStuff() async;

func doStuff() async {
    await doOtherStuff()
}

to this:

func doStuff() async {
    async let t = doOtherStuff()
    await t
}

Assume all of this code is in a class with @MainActor (i.e., we care which executor it runs on and want to stay on that executor both in doStuff and in doOtherStuff ).

I think if those two code blocks do different things then this feature is going to be extremely confusing.

The current semantics is that child tasks do not "inherit" the actor in which they were created. Rather, they go onto the global executor so they can execute concurrently with the body that created them (here, it's doStuff). This is the default because the point of async let is to introduce concurrency.

One important thing your example is missing is the declaration of doOtherStuff(). If it's also part of the @MainActor, e.g., you have code like this:

@MainActor func doOtherStuff() { ... }

then that code will end up running on the main actor anyway. If it's not part of the main actor:

func doOtherStuff() { ... } // not part of an actor at all!

then it runs concurrently.

One important thing to internalize about the actor model is that a declaration knows what actor it needs to run on, and Swift makes sure that happens. The place where you initiate a call to the declaration is far less important.

async let doesn't inherit actor context because doing so would introduce unnecessarily serialization on the actor, and the actor model already ensures that you'll come back to the actor when needed.

Here's another instance of this same question/sentiment:

@QuinceyMorris

In code running on a serial executor, such as the main thread, asyncAttached let seems a better default choice than asyncDetached let , because running "on the same executor" would help to avoid data races and other thread safety issues. It should require thought and deliberate choice to introduce parallelism to this serial execution environment.

async let is the deliberate choice to introduce concurrency. Immediately eliminating that concurrency by having the child task go back to the main actor---even if you don't need it---would undo the benefits. We'll require a hop back to the main actor when you use anything that needs to be on the main actor.

@adamkemp

Also, if those do different things then we're missing a feature that allows you to separate the initial call from the await without changing the executor that the call is run on.

FWIW, for (instance) actors this feature was part of the SE-0313 review, but has been subsetted out of that proposal due to concerns about how the feature behaved. It could come back later, of course.

Doug