{"id":29479,"date":"2020-07-13T16:30:03","date_gmt":"2020-07-13T20:30:03","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=29479"},"modified":"2020-07-30T16:28:55","modified_gmt":"2020-07-30T20:28:55","slug":"implicit-capturing-of-self-in-swift-5-3","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2020\/07\/13\/implicit-capturing-of-self-in-swift-5-3\/","title":{"rendered":"Implicit Capturing of Self in Swift 5.3"},"content":{"rendered":"

John Sundell<\/a>:<\/p>\n

\n

In Swift 5.3, however, using self<\/code> in the above kind of situation is no longer required, and we can simply access properties and methods belonging to value types (such as SwiftUI views, or any other type of struct) without any additional prefixes — regardless if that’s done within an escaping closure or not[…]<\/p>\n

That’s really neat, and further makes SwiftUI’s DSL<\/a> feel even more lightweight. However, it’s important to remember that the same kind of capturing still occurs — meaning that the above ListView<\/code> value (and the ListViewModel<\/code> instance that it contains) will still be captured by our closures. Within the context of SwiftUI, though, that’s not likely to become a problem — since SwiftUI views are just lightweight structs that don’t hold any strong references to their subviews.<\/p>\n<\/blockquote>\n\n

This is perhaps confusing<\/a>, but it doesn’t seem like it will cause unwanted captures because it’s limited to value types.<\/p>\n\n

SE-0269<\/a>:<\/p>\n

\n

Whenever self<\/code> is declared explicitly in an escaping closure’s capture list, or its type is a value type, any code inside that closure can use names which resolve to members of the enclosing type, without specifying self.<\/code> explicitly.<\/p>\n

[…]<\/p>\n

While this proposal opens up implicit self<\/code> in situations where we can be reasonably sure that we will not cause a reference cycle, there are other cases where implicit self<\/code> is currently allowed that we may want to disallow in the future. One of these is allowing bound method references to be passed into escaping contexts without making it clear that such a reference captures self<\/code>.<\/p><\/blockquote>\n\n

I still think closures are an area of Swift that needs work. I wish it were harder to accidentally strongly capture self<\/code> in reference types and less verbose to use it weakly.<\/p>\n\n

Previously:<\/p>\n