Weak assignment in Combine08 Apr 2020 ⇐ Notes archive
(This is an entry in my technical notebook. There will likely be typos, mistakes, or wider logical leaps — the intent here is to “let others look over my shoulder while I figure things out.”)
Publisher.assign(to:on:) comes with a pretty big warning label,
Subscribers.Assigninstance created by this operator maintains a strong reference to
and we need to read this label when piping publishers to
@Published properties in
Of course, we could do the
receiveValue dance. But, that’s a bit of ceremony.
My first instinct was to
assign and PR’d it to
CombineExt, in case it’d help others, too. And with some distance and thoughtful feedback from both Shai and Adam, I decided to re-think that instinct.
There’s a few downsides to
- It crowds an already packed
- In its current form, it doesn’t relay which argument is
weakly captured. A clearer signature would be
.assign(to:onWeak:)(and similarly, for an
Adam mentioned a couple of alternatives:
weakkeyword to a sort of function by way of a
WeakBoxtype and assign onto it. I tried to make this work—learning more than I bargained for about dynamic member lookup along the way—and ran into a tradeoff dead end.
Encode the weak capture semantics at the type level à la the
Bindingspackage. Which, felt a bit out of scope for
CombineExt, since it’s more of an operator collection.
So, I’m back to where I started and with a slightly modified overload. Gist’ing it below for the curious.
Now call sites can read—
Ah! Almost forgot. Writing tests for the operator had me reaching for
Swift.isKnownUniquelyReferenced(_:)—“a [free-function] I haven’t heard [from] in a long time, a long time.”