Question about `SerialDisposable`

[Adrian M.]

I'm currently learning the project while trying to understand every single bit of it.

As far as I understood the design of Disposable types included in the Disposable.swift file, I think I might have found a small issue (maybe harmless, but potentially a bug?).

For example CompositeDisposable will clear the Atomic's value and potentially remove all the retained references to the Disposable objects. Then if you try to add a new disposable to the CompositeDisposable, but the CompositeDisposable itself is already disposed, it will dispose the passed Disposable and reject retaining the reference into the bag.

Now if I compare that behavior with SerialDisposable, the dispose() method does the same. However the setter on the inner property does not reject the value if the SerialDisposable is already disposed, but retains the reference.

Is this by design or just overlooked?

I thought it would be more like this:

set(disposable) {
+  if isDisposed {
+    disposable?.dispose() // Dispose and do not retain
+  } else {
    _inner.swap(disposable)?.dispose()
+  }
-
-  if let disposable = disposable, isDisposed {
-    disposable.dispose()
-  }
}

[Matt Diephouse]

I think this is by design. For one thing, setting inner can't return a value that indicates whether the value was set. The current behavior makes more sense to me.

[Adrian M.]

Hi @mdiep thank you for answering my question and sorry about closing / re-opening the issue (I was testing GitHawk on the iPad while browsing this repo). I do not follow your point, can you elaborate further?

The misalignment that I discovered here is that when SerialDisposable is already disposed you can take a different Disposable (disposed or not, it does not matter) and assign to inner so it will still be retained. Sure this is unlikely to happen anywhere because doing that makes simply less sense, but it's a potential source for an issue by allowing retaining a new disposable on a already disposed SerialDisposable.

[Matt Diephouse]

What I mean is that adding a disposable to a CompositeDisposable is a failable operation. You call add and get back get back a Disposable? that tells you whether your disposable was added. Because SerialDisposable lets you assign to a property, it can't return a value that indicates whether your disposable was set as the inner disposable.

[Adrian M.]

Because SerialDisposable lets you assign to a property, it can't return a value that indicates whether your disposable was set as the inner disposable.

Well I understand that semantics, but if the behavior of rejecting a new disposable after the SerialDisposable is disposed would be documented it should lead to a more predictable and less error prone state of the type, don't you think?

[Matt Diephouse]

I've never run into a case where this would cause an issue. Have you seen problems from this?

[Rui Peres]

Hello. 👋 Thanks for opening this issue. Due to inactivity, we will soft close the issue. If you feel that it should remain open, please let us know. 😄