SE-0472: Starting tasks synchronously from caller context

[kabiroberai]

@Jon_Shier

In the more realistic case where API isn't @MainActor (until that's the default?), this likely wouldn't fix the issue, as the Task would still have to be enqueued to handle the suspension. (Hopefully that's all correct.)

This sounds about right per my understanding, and fwiw I intentionally marked API as @MainActor to keep the proof-of-concept simple. That said, I don't think the demo is as unrealistic as it may seem for two reasons:

1. In a large number of cases, you'll probably be interacting with an Observable ViewModel, so if I were to rename API to @MainActor @Observable final class APIViewModel it would look a lot more idiomatic and likely.
2. Even if we were using a non-MainActor API, we could achieve the same result by inheriting the caller's isolation. That is,

func loadName(isolation: isolated (any Actor)? = #isolation) async -> String

This is pretty verbose today but that's why I'm looking forward to SE-0461 which makes this the default behavior.

The one thing that gives me pause is this comment

@ktoso

In general it is not possible to answer if a potential suspension point will suspend or not statically

@ktoso am I right in understanding that the two cases I mentioned (1. calling a @MainActor async func from another @MainActor async func, and 2. calling a function that inherits #isolation) are guaranteed to elide the scheduling overhead? That's the understanding I've had so far, and if so it would make it possible to use this API in ways that provide deterministic behavioral guarantees. If this is not the case, I'm unsure what behaviors the programmer can rely on this API providing, if any, save for what's effectively a syntactic transformation of factoring out explicitly synchronous code from the prefix of a closure.