SE-0296: async/await

[Douglas_Gregor]

@xwu

This is a great point; it makes lots of sense and is explained very clearly. Can it be recorded for posterity in the proposal text?

Sure, I stubbed out some wording here: [SE-0296] Add Alternative Considered for async/await as Futures sugar · DougGregor/swift-evolution@0c1d578 · GitHub

@Nevin

You were able to quickly summarize why you see async / await as a better fit for Swift than basing everything on futures. That shows you have already thought about the matter.

In other words, you have already considered a futures-based concurrency system, and you have determined that async / await is preferable. That is the type of information which should be documented in the “alternatives considered” section.

Yes, we had considered it. It's not a good match for Swift. I've now documented why it in Alternatives Considered for posterity.

There is no way for authors to predict what people in a review will think is an idea that "must" be considered as an alternative or else the proposal is incomplete. That's what discussion is for, and some things that come up in discussion get promoted to "Alternatives Considered."

Doug

[Douglas_Gregor]

@Mordil

@davedelong as a side-note, it was explicitly mentioned through the Result proposal review that the intention is that the type might end up deprecated and was a stop-gap for when we had a first-class concurrency model so that you just annotate async throws on a method and never deal with Result again.

Part of the reason that Result was kept out of the standard library so long is because it's duplicative of throws, which causes confusion. Result was also primarily motivated by asynchronous code patterns that we knew could be subsumed by an async analogue to throws in time. But we also knew that "in time" was going to be several years, and having numerous Result re-implementations in the ecosystem.

async/await may only have come up for formal review two weeks ago, but this approach to solving the problem has been around in the Swift community for ~4 years.

Doug

[Nevin]

@Douglas_Gregor

There is no way for authors to predict what people in a review will think is an idea that "must" be considered as an alternative

But there is a way for the authors to list the alternatives they actually did consider.

[Nevin]

@Nevin

The proposal includes these lines:

Instead, think of an asynchronous function as an ordinary function that has the special power to give up its thread. Asynchronous functions don’t typically use this power directly; instead, they make calls, and sometimes these calls will require them to give up their thread and wait for something to happen. When that thing is complete, the function will resume executing again.

It says that an async function doesn’t typically give up its thread directly. This implies that an async function can give up its thread directly.

Is that capability in fact being proposed?

If so, what is the proposed spelling?

When an async function directly gives up its thread, how can it specify when to resume execution?

I still have not seen a response to this. Perhaps I missed it?

[Lantua]

@kavon

Use suspends (or something other than async ) in the function type, and keep async let to mean spawning a new task and binding an opaque promise / future, etc.

suspend is a little long. Maybe we could shorten it to sus...

I’ll see myself out...

[Ben_Cohen]

The review period has now ended and the proposal has been accepted.

Thanks to everyone who participated!