Factory closure lifetime differs between .create and .deferred, subscriptions to the latter keep its factory closure alive

[nikolaykasyanov]

⚠️ it's an issue report in the form of a pull request, to have a self-contained runnable examples.

Short description of the issue:

Each subscription to Observable.deferred captures its factory closure, unlike Observable.create.

Expected outcome:

Intuitively I would expect Observable.deferred to not keep its factory closure alive longer than required in subscriptions, but that's probably not the best argument.

Alternatively, I'd expect this behavior documented because I recognize that changing it at this point might be a very breaking change.

What actually happens:

.deferred is implemented in such a way each subscription to it retains its factory closure:

RxSwift/RxSwift/Observables/Deferred.swift

Line 71 in 2ff073f

let sink = DeferredSink(observableFactory: self.observableFactory, observer: observer, cancel: cancel)

Self contained code example that reproduces the issue:

See the test cases in this PR. testDeferredFactoryClosureLifetime fails while testObservableFactoryClosureLifetime passes.

RxSwift/RxCocoa/RxBlocking/RxTest version/commit

6.6.0

Platform/Environment

• iOS
• macOS
• tvOS
• watchOS
• playgrounds

How easy is to reproduce? (chances of successful reproduce after running the self contained code)

• easy, 100% repro
• sometimes, 10%-100%
• hard, 2% - 10%
• extremely hard, %0 - 2%

Xcode version:

  Version 14.3.1 (14E300c)

⚠️ Fields below are optional for general issues or in case those questions aren't related to your issue, but filling them out will increase the chances of getting your issue resolved. ⚠️

Installation method:

• CocoaPods
• Carthage
• Git submodules

I have multiple versions of Xcode installed:
(so we can know if this is a potential cause of your issue)

• yes (15.0.0-Beta.4)
• no

Level of RxSwift knowledge:
(this is so we can understand your level of knowledge
and formulate the response in an appropriate manner)

• just starting
• I have a small code base
• I have a significant code base

[danielt1263]

I made a PR with the fix. #2534

[nikolaykasyanov]

Closing in favour of #2534.