Etymology of "sink" in SwiftUI / Combine?

Question

I'm joining development on an existing SwiftUI / Combine iOS project, which is my first exposure to the technology.

The names of functions like assign(to:on:) are easy enough to grok, but I'm lost at sink.

This function is mentioned in some of the most basic Apple documentation, but seemingly never defined.

Combine provides two built-in subscribers, which automatically match the output and failure types of their attached publisher:

• sink(receiveCompletion:receiveValue:) takes two closures. The first closure executes when it receives Subscribers.Completion, which is an enumeration that indicates whether the publisher finished normally or failed with an error. The second closure executes when it receives an element from the publisher.

https://developer.apple.com/documentation/combine/receiving-and-handling-events-with-combine

What is a "sink" function in the the world of SwiftUI, Combine, reactive programming?

Why is it called "sink"? What's the etymology? What's the meaning?

Is it intended to refer to "sync" as in syncing? Kitchen sink? Heat sink? Going below the surface? Why is the name "sink"?

Answer 1

let's start from the beginning.

What is Combine?

The Combine framework provides a declarative Swift API for processing values over time. These values can represent many kinds of asynchronous events. Combine declares publishers to expose values that can change over time, and subscribers to receive those values from the publishers.

in Reactive programming, the connection between a Publisher (Observable) and Subscriber (Observer) is called a Stream. The reason behind this naming is that this connection really looks like a stream that an Event Publisher uses to deliver things (Events) to the observers.

During this stream, just like a real stream we can create branches or transform it into a completely new stream using Operators like Map, ...

Why Sink?

the "Sink" function represents the end of the stream and it means that you do not access the stream anymore after you sink it. You can't have any operator after Sinking a stream.

We have upstream and downstream as well Which makes the naming more reasonable.

         upstream          downstream
source <--------- operator -----------> consumer/further operators 

I think it is worth mentioning that because of functional programming and function composing, we need an executor, I mean you can compose Operators together as much as you want on a stream, but they don't do anything if you don't run the composed function. Sink and Assign are considered as Executors (It's my personal naming) that execute the final composed function and handle the results.