SE-0461: Run nonisolated async functions on the caller's actor by default

[hborla (Holly Borla)]

@Jumhyn

But I worry that the specific spelling requires a bit too much 'reasoning' to understand the actual consequences. I suppose part of the objection here is that when I've deliberately made use of the 'nonisolated async functions run on the global executor' behavior, I've generally thought of that as a more addititve step to move code to a specific executor rather than a subtractive step of 'remove all possible isolation concepts from this code'. So to me something like @execution(concurrent) feels like a more direct expression of why I'm actually using the feature.

I find this argument very convincing. A better spelling for a specific executor that a function runs on (which I think was suggested by somebody else upthread) is @executor(concurrent) / @executor(global).

Personally, I think it's much more important to optimize the syntax for the @execution(concurrent) attribute, because this attribute will be used long term to move functions and closures off of actors. I view @execution(caller) as necessary for the transition to this new behavior, but it's not a syntax that will stick around long term in Swift codebases; the ideal end state is that this is expressed via the default behavior for (explicitly or implicitly ) nonisolated async functions. I'm also open to spelling @execution(caller) / @executor(caller) differently from @execution(concurrent) / @executor(concurrent) / @executor(global) instead of using one base attribute if we think there's a better option.

This direction definitely requires us to standardize the term for "the generic, non-actor executor" / "the global concurrent executor" / your favorite term for this executor. That's a good thing though - we have too many terms for this executor floating around.