# Why “sink?”

⇐ Notes archive

(This is an entry in my technical diary. There will likely be typos, mistakes, or wider logical leaps — the intent here is to “[let] others look over my shoulder while I figure things out.”)

“Sink” is a word you’ll see all over reactive declarative programming, and Combine is no exception.

There’s Subscribers.Sink (the subscriber behind the two Publisher.sink overloads), CombineExt.Sink (albeit internally-scoped), and similarly in the framework’s predecessor, RxSwift.Sink.

The often-cited kitchen sink metaphor aside, the term’s etymology is a bit unclear. My guess would be it borrows from the corresponding graph theory term.

A local sink is a node of a directed graph with no exiting edges, also called a terminal.

We can view a subscription graph as a directed graph between upstream publishers, through various operators, and down towards local sinks (which, in Combine’s language are Subscribers).