How do continuations bridge callback APIs, and what is the difference between checked and unsafe?

A continuation lets an async function wait for a callback: await withCheckedContinuation { c in legacy { c.resume(returning: $0) } } (or withCheckedThrowingContinuation with resume(throwing:) and resume(with: Result)). The task suspends until some code calls resume, then continues with that value. The contract is strict: you must resume exactly once on every path, including the failure and cancellation ones. Resuming twice or never is a bug, and the two variants differ in how they tell you. withCheckedContinuation (the default choice) detects misuse: resuming a second time is a fatal error (“tried to resume its continuation more than once”), and a continuation dropped without resuming logs a leak warning (and the task would wait forever). withUnsafeContinuation does the same job with no checks and slightly less overhead: a double resume is undefined behaviour and a missing one is a silent hang. Use checked while developing and in nearly all production code; reach for unsafe only where you have measured the cost.

Design points. Capture the continuation in the callback and make sure the callback is called exactly once by the API’s contract; if it can be called many times, use a stream instead. Handle the “delegate was never called” and “object deallocated before completion” cases (resume with an error in deinit or on cancellation, using withTaskCancellationHandler). Do not resume while holding a lock the continuation’s waiter needs. The function you bridge should be @Sendable-safe: the callback often runs on another thread, so the continuation (which is Sendable) is the only thing it should touch. Prefer wrapping an old API once, in an extension, so the rest of the code never sees the callback.