Perfect!
That’s exactly what I want: the body of asynchronous is executed asynchronously.
Heh, it’s interesting that we see the same code, share the same understanding of how it works, and draw such different conclusions. I think code using the asynchronous function is highly readable, and straightforward to understand.
Now, I’m not currently advocating that a function like asynchronous should be included in the standard library, but I find the code using it to be much nicer than the (otherwise identical) code using Task.runDetached.
• • •
Personally, if I were designing an async system, I would probably start by seeing if there’s a workable model where sync and async functions can both call each other directly.
The basic story would be that the result of an async function needs to be awaited before use, and a sync function cannot use await.
So you can call all the async functions you like from synchronous code, but you can never use their return values. They just do stuff in the background.
However, if async let were a first-class construct, then the result of an async call could be stored as such and passed into another async function which could then await it.
In my mind, that would greatly simplify the mental model: an async function is always asynchronous; you can call it from anywhere, without any ceremony; and if you want its return value then you need to await it.
I don’t know enough about the implementation side of things to say whether that can be made into a viable and efficient system, but from a naive perspective it’s how I would want to think about asynchronous functions.