{"id":30940,"date":"2020-12-07T16:30:33","date_gmt":"2020-12-07T21:30:33","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=30940"},"modified":"2022-05-05T13:49:09","modified_gmt":"2022-05-05T17:49:09","slug":"swift-proposal-for-async-await","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2020\/12\/07\/swift-proposal-for-async-await\/","title":{"rendered":"Swift Proposal for async\/await"},"content":{"rendered":"

SE-0296<\/a> (via Doug Gregor<\/a>):<\/p>\n

This design introduces a coroutine model<\/a> to Swift. Functions can opt into being async<\/code>, allowing the programmer to compose complex logic involving asynchronous operations using the normal control-flow mechanisms. The compiler is responsible for translating an asynchronous function into an appropriate set of closures and state machines.<\/p>

This proposal defines the semantics of asynchronous functions. However, it does not provide concurrency: that is covered by a separate proposal to introduce structured concurrency, which associates asynchronous functions with concurrently-executing tasks and provides APIs for creating, querying, and cancelling tasks.<\/p>

[…]<\/p>

Because only async<\/code> code can call other async<\/code> code, this proposal provides no way to initiate asynchronous code. This is intentional: all asynchronous code runs within the context of a “task”, a notion which is defined in the Structured Concurrency<\/a> proposal. That proposal provides the ability to define asynchronous entry points to the program via @main<\/code> […]<\/p><\/blockquote>\n\n

Previously:<\/p>\n