[Pitch] await blocks

[mattie]

@broken-circle

Curious if it might be worth introducing a new compound form of do

I'm uncertain how complex this would be to pull off syntactically. And I'm just slightly wary of tying this too closely with error handling, but definitely an interesting thought.

@NotTheNHK

To me, neither await nor await do clearly conveys that execution happens on an executor other than the current actor.

Yeah, that's the core objection. On the one hand, the compiler will not let you get away with doing anything unsafe. And the task's execution will remain linear. So I think that any mistakes would be immediately surfaced to the programmer in the form of diagnostics. But this stuff is complex so no doubt there's something I'm not thinking of

@NotTheNHK

What about implicit actor isolation? Would we disallow it?

Are you talking about isolation inheritance for closures?

@ktoso

What you’re proposing is actually just the run method taking a closure which exists on MainActor but we intentionally did not offer on “any actor”. And we were not able to semantically express it on “any global actor” — which is a thing we should actually fix.

I've now thought on this. I totally agree that extending this to work for any global actor is desirable. I think it is unfortunate that MainActor.run does not accept an async function, but I don't know if changing it now could be possible. There also is a Sendable constraint necessary for that version which would not be necessary specifically in the nonisolated case. And that matters a lot for the usability here.

And then, on top of that, there's the problem of how to express .run on the global executor. I have not thought on this one aspect too much, but it seems surmountable.

@ktoso

I’d rather focus on closure isolation control first, and only then see if any such syntax is even necessary.

This is also a super-interesting question. At the time it was originally looked at, @concurrent was not a thing, so I think that an explicit nonisolated would have been sufficient. But now, that's no longer the case. Which seems like it would mean an explicit @concurrent would still be necessary. Otherwise, I think the intended behaviour would have to be nonisolated(nonsending).

And then, I find myself, again, just lamenting this doesn't work today:

await { @concurent in
// invalid because this closure is inferred to be synchronous
}()

I get that changing this, now, would likely be source-incompatible. But, wouldn't it just mean that if you actually wanted a synchronous function, you'd be required to add an explicit signature?

await { @concurent () -> Void in
// a default of async means this would have to be explicit
}()

This seems like it could be a reasonable middle ground? I'm still believe that it does not make sense for synchronous functions to be @concurrent. But perhaps this is a path to an improvement that also does not close the door permanently?