If it's down to the naming of Task.runDetached
, let's please talk about this in the discussion of the task library.
That's what this proposal does.
That's effectively the semantics of Task.runDetached
, but you want a non-awaited call to an async
function to behave that way? Again, that breaks the mental model of structured concurrency. Consider:
func f() async { }
func g() async { }
func h() async {
f()
await g()
}
In the current proposal, the call to f()
is an error. If calls to asynchronous functions without await became detached tasks, then this little error of omission with await
now means that f
and g
are running asynchronously when you didn't mean them to.
That's a future. Task.runDetached
returns one (called Task.Handle
, subject to design discussion elsewhere). async let
is intentionally hiding the future to keep the model simpler. async let
is part of Structured Concurrency, not this proposal.
Doug