[Chapter 18] Implementing a ShareReplay operator, subscribe to upstream

Hello @fpillet ,

Thank you for the great article for in-depth explanations!

I am wandering about snippet of code below. Why API design upstream.subscribe(sink) doesn’t return subscription as in other cases for memory management/cancelling logic?

  guard subscriptions.count == 1 else { return }
      // 38
      let sink = AnySubscriber(
        // 39
        receiveSubscription: { subscription in
          // 40
          subscription.request(.unlimited)
        },
        receiveValue: { [weak self] (value: Output) -> Subscribers.Demand in
            self?.relay(value)
            return .none
          },
          receiveCompletion: { [weak self] in
            self?.complete($0)
        }
      )

      upstream.subscribe(sink)

From docs it says Attaches the specified subscriber to this publisher. But do we need to retain publisher to make sure it’s not deallocated (generally, in all the cases)? Or there’s some shared subscription store for all publishers under the hood that’s updated on life cycle events for publisher – e.g. complete?

Thanks,
Dzmitry.

@Audrey @scotteg @freak4pc @icanzilb , you could please support?

Thanks,
Dzmitry.

No, you don’t do any memory management in here. subscribe(_:) doesn’t return anything: you are attaching a subscriber to the publisher but you don’t create a subscription that returns an AnyCancellable.

1 Like