/*:#localized(key: "WrappingUp")
 # Wrapping up

 The point of `async`/`await` is code that waits without blocking: it reads
 top to bottom while the thread stays free for other work. The one idea to
 hold onto is that `await` marks a place your function can *pause and hand
 its thread back*, not a place it freezes. Everything below follows from
 getting that picture right.

 * An **`async`** function may pause and resume; you call it with
 **`await`**, a *possible* suspension point that frees the thread rather than
 freezing it.
 * A **task is not a thread.** Swift multiplexes many tasks onto a small
 cooperative pool (~one thread per core); a suspended task hands its thread
 back and may resume on a different one. Blocking a pool thread (e.g.
 `Thread.sleep`) is the classic mistake: suspend, don't block.
 * Pitfall: don't await independent work back-to-back; two sequential
 `await`s stack their waits (the accidental 2-second latte). Use
 **`async let`** to start independent work at once so the waits overlap and
 the total time shrinks.
 * Pitfall: an `async let` you never `await` is cancelled at the end of the
 scope and its result thrown away. `async let` is a *promise to await*: keep
 it.
 * You can only `await` inside an async context; use **`Task { }`** to cross
 over from synchronous code (`await` at the top level won't compile).
 * **`async throws` + `try await`** brings errors back into plain
 `do-try-catch`, far cleaner than completion-handler error plumbing.
 Forgetting `try` is a compile error, not a silent bug.

 ---
 
 ## Up next

 [Tasks and cancellation](Tasks%20and%20Cancellation.playgroundchapter/Overview): what a `Task` really is, how tasks form a tree,
 and how to stop work you no longer need.

 [Previous](@previous)  |  page 8 of 8
 */
