Why does the Combine Publisher protocol have receive<S> and subscribe<S> with identical constraints?

Question

Here's the Publisher protocol:

public protocol Publisher {
  associatedtype Output
  associatedtype Failure: Error

  func receive<S>(subscriber: S) 
    where S: Subscriber, Self.Failure == S.Failure, Self.Output == S.Input
}

The receive(subscriber:) function requirement is meant to attach a subscriber to the publisher. However, in a protocol extension, there's a very similar function:

extension Publisher {
  public func subscribe<S>(_ subscriber: S) 
    where S: Subscriber, Self.Failure == S.Failure, Self.Output == S.Input
}

Both receive(subscriber:) and subscribe(_:) have identical constraints on the functions. I'm wondering why there's a need for both

Answer 1

If you take a look at the subscribe method in a disassembler, you'll find that it can potentially do a bunch of debug/diagnostic work. It refers to private types called Combine.SubscriberTap and Combine.DebugHook.

The Combine framework's architecture is quite “thin”, really. The receive(subscriber:) method creates a direct connection between a Publisher and a Subscriber. After this connection is established, these objects can talk to each other without calling through any Combine code. (Compare this with the SwiftUI architecture, where you create View objects but SwiftUI transforms them into completely different objects like UIViews under the hood.)

Apple encourages you to use the subscribe(_:) method instead of calling receive(subscriber:). This gives the Combine framework a chance to connect your publisher and subscriber indirectly, routing their communication through its own debug hooks.