SE-0296: async/await

[Douglas_Gregor]

@Nevin

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 .

If it's down to the naming of Task.runDetached, let's please talk about this in the discussion of the task library.

@Nevin

The basic story would be that the result of an async function needs to be await ed before use, and a sync function cannot use await .

That's what this proposal does.

@Nevin

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.

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.

@Nevin

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.

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