Implicit Capturing of Self in Swift 5.3
In Swift 5.3, however, using
selfin 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[…]That’s really neat, and further makes SwiftUI’s DSL feel even more lightweight. However, it’s important to remember that the same kind of capturing still occurs — meaning that the above
ListViewvalue (and theListViewModelinstance 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.
This is perhaps confusing, but it doesn’t seem like it will cause unwanted captures because it’s limited to value types.
Whenever
selfis 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 specifyingself.explicitly.[…]
While this proposal opens up implicit
selfin situations where we can be reasonably sure that we will not cause a reference cycle, there are other cases where implicitselfis 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 capturesself.
I still think closures are an area of Swift that needs work. I wish it were harder to accidentally strongly capture self in reference types and less verbose to use it weakly.
Previously:
Update (2020-07-30): Sami Samhuri:
It would be nice to concisely say that a closure should be discarded when a weakly-captured param goes away. I imagined what that could look like and now I want @ClosureWrapper.
