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

 A task begins running the moment you create it, and cancelling it is a polite
 *request*, not a stop button. Almost every surprise in this chapter traces
 back to those two facts. Lean toward structured work bound to a scope, and
 treat the takeaways below as the rules that keep cancellation honest.

 * A `Task` **starts immediately** when created; read its result with `await
 task.value` (or `await task.result` for a `Result` you can switch on).
 * **Structured** tasks (`async let`, task groups) are bound to a scope and
 can't outlive it. **Unstructured** tasks (`Task`, `Task.detached`) float free
 and are your responsibility; pitfall: a handle-less `Task { }` can't be
 awaited or cancelled.
 * A plain `Task` **inherits** priority and actor context; `Task.detached`
 inherits **nothing**: a sharp tool that's rarely what you want.
 * Tasks form a **tree**: errors propagate up (cancelling siblings),
 cancellation propagates down to every child.
 * Cancellation is **cooperative** and never a forced stop: `cancel()` only
 sets a flag, so check it with `Task.isCancelled`, `try
 Task.checkCancellation()`, or a throwing `Task.sleep` periodically, in any
 long-running work, or "cancel" is a lie.

 ---
 
 ## Up next

 The next chapter, [AsyncSequence and AsyncStream](AsyncSequence%20and%20AsyncStream.playgroundchapter/Overview),
 turns from single tasks to whole *series* of values over
 time: consuming and producing them with `AsyncSequence` and `AsyncStream`,
 using `await` in a loop.

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