Exercise 2: Why Automatic Stop-on-Cancellation Is a Genuine Advantage Over Manual Combine Cleanup — Possible Solution ============================================================================================================================== A Combine subscription created via .sink { } returns a real AnyCancellable value that the calling code is responsible for actually STORING somewhere - typically as a real stored property on the object that created the subscription - for as long as that subscription should remain genuinely active. If that AnyCancellable is ever allowed to be deallocated prematurely (or simply never stored in the first place), Combine will silently cancel the subscription right then, often producing a real, confusing bug where a publisher appears to simply stop delivering values with no obvious cause in the code that's actually failing. Beyond that storage requirement, cleanly stopping a Combine subscription at the CORRECT real moment - for instance, exactly when a particular screen disappears, not sometime vaguely afterward - often requires the developer to explicitly call .cancel() at the right real point in the code, or wire the cancellation to a view's own lifecycle by hand. Missing or mistiming that call is a real, common and genuinely easy-to-introduce source of bugs: a subscription that keeps running (and potentially keeps a whole object graph alive longer than it should, echoing this course's own earlier ARC/retain- cycle material) well past the point it was actually still needed. notifications(named:)'s own real automatic behavior removes this entire category of manual bookkeeping. Because observation is structurally tied to the real for await loop's own lifetime - itself tied to the surrounding real Task - there's no separate cancellable value to remember to store, and no separate cancel() call to remember to make at the right moment. Exiting the loop, or the Task being genuinely cancelled by the framework (for instance, via Fundamentals Chapter 9's own .task {} auto-cancellation on view disappearance), automatically and correctly stops the underlying observation with zero further code required. ANSWER: A Combine subscription requires the developer to explicitly store its AnyCancellable and correctly time an eventual cancel() call - forgetting either is a real, common source of bugs, including subscriptions or object graphs staying alive longer than intended. notifications(named:)'s own automatic stop-on-cancellation ties observation directly to the for await loop's own real lifetime, removing that entire manual bookkeeping requirement - exiting the loop or cancelling its Task correctly stops observation with no separate storage or explicit cleanup call needed at all. WHY THIS WORKS AS AN ANSWER ------------------------------ This identifies the real, concrete manual-bookkeeping burden Combine's own AnyCancellable pattern carries and explains precisely how tying observation to the for await loop's own lifetime removes it.