{"id":40255,"date":"2023-08-04T13:31:56","date_gmt":"2023-08-04T17:31:56","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=40255"},"modified":"2023-08-15T10:24:45","modified_gmt":"2023-08-15T14:24:45","slug":"avoiding-implicit-retain-cycles-when-using-swift-function-references","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2023\/08\/04\/avoiding-implicit-retain-cycles-when-using-swift-function-references\/","title":{"rendered":"Avoiding Implicit Retain Cycles When Using Swift Function References"},"content":{"rendered":"

Svein Halvor Halvorsen<\/a>:<\/p>\n

Even though we capture self<\/code> unonwed in the outer closure, the callbacks that gets registered with the socket, are captured strongly. So even when the object above is released from where ever it was created, the object is still kept alive.<\/p>

[…]<\/p>

The [unowned self] in<\/code> and argument list is just boilerplate, repeated over, with no other purpose than to pass arguments from one function (the in-line closure) on to the next (the actual event handler functions).<\/p>

[…]<\/p>

What if we took self.dynamicType.onChatMessageReceived<\/code> from the second event handler above, but without the argument (self)<\/code>, and passed that as a parameter<\/em> to our wrapper function, together with a reference<\/em> to self<\/code>? Maybe we could then capture that reference unowned, and pass the unowned instance reference<\/em> to the class function<\/em> to get an instance function<\/em>, without creating a retain cycle.<\/p><\/blockquote>\n

As he says, this works but it is far from optimal. I wonder if there’s a way to make it better with macros.<\/p>\n\n

Sean Heber<\/a>:<\/p>\n

In the first line, Swift will helpfully tell me that I’m accidentally capturing self<\/code>, but in the second line there’s no warning whatsoever.<\/p><\/blockquote>\n\n

Previously:<\/p>\n