11.10 · Cancelling and completing, the cycle that survives a deinit, and failure types

Two kinds of mistakes remain once the operators are right: pipelines that live longer (or shorter) than intended, and error types that do not line up.

Mental model. A subscription lives as long as something holds its cancellable, and a cancellable held by the object whose closure it runs is a cycle. Failure types must match exactly.

Ending and holding

Completing early, cancelling, and the cycle through a stored cancellable.

1. How do you end a pipeline: prefix(untilOutputFrom:), cancel and completion, and why does a sink that captures self and is stored on self never deinit? 11.10.1 · L3
   A pipeline ends in one of three ways: the upstream completes or fails; a downstream operator completes early; or the subscriber cancels.…

Types

Matching failure types when you combine or convert publishers.

1. Why does merging or combining publishers fail to compile with “types Never and E must be equivalent”, and how do setFailureType, mapError and tryMap fix it? 11.10.2 · L3
   Every publisher has an Output and a Failure, and operators that combine publishers (merge, combineLatest, zip, flatMap) require the failure types to be…

More in Combine

• 11.1 · Publisher, Subscriber, Subscription and demand
• 11.2 · map, scan, combineLatest, flatMap, switchToLatest, debounce, share
• 11.3 · PassthroughSubject, CurrentValueSubject and @Published
• 11.4 · receive(on:), subscribe(on:) and where code runs
• 11.5 · AnyCancellable, subscription lifetime, and failure versus Never
• 11.6 · Combine versus async/await, and testing pipelines
• 11.7 · Operator behaviour, error placement, retry, flatMap limits and debugging
• 11.8 · Future versus Deferred, subject replay, share, and bridging to async
• 11.9 · Which thread each stage runs on, schedulers, throttle versus debounce, and timers