I can see your point - there is still a reference to memory and you could write code to dispose of the memory (hey! What do you know, that’s exactly what my blog post shows how to do!) and so by a strict definition of “memory leak”, sure, it’s not a “leak”. But it will be a memory leak if some new programmer copies the pattern in their root view controller (like in this simple example) and doesn’t understand that they are accumulating memory over time until their app crashes.
Unfortunately, the phrase “memory leak” seems to have triggered a bit of a defense reaction and overshadowed my point which was feedback that the book would be better if it pointed this issue out for less experienced programmers and taught readers a pattern to use in that case.
Because of the reaction my comments got here it seemed like I needed to write a blog post to point out the issue and provide at least one strategy myself - so I did.
In my blog post I specifically said,
“The problem with this pattern in this particular case, and other similar situations, is that the any
AnyCancellable is never removed from the subscriptions
Set and so it’s a memory leak. Sometimes this doesn’t matter - when the enclosing scope is going to go away and the code is only called once relatively soon before existing scope cleans up memory.”
That all seems to be very specifically explaining what the issue is, when it’s an issue, and when it isn’t. Doesn’t seem “unfair/misleading” to me, but I’m sorry you feel that way; it wasn’t my intent that anyone should feel insulted or attacked.
In my blog post I made a point of linking to your book and saying “It’s a good book on Combine”, which I thought you would feel was of benefit to you; clearly you do not and so I have removed reference to your book from the post.
I have also heard your feedback and modified the language in the post to remove the phrase “memory leak”, since it seems to cause problems, and I tried to clarify the language in the section quoted above.
So, thanks for the feedback. Edits were made.