Implicit Capturing of Self in Swift 5.3

John Sundell:

In Swift 5.3, however, using self 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[…]

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 ListView value (and the ListViewModel 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.

This is perhaps confusing, but it doesn’t seem like it will cause unwanted captures because it’s limited to value types.

SE-0269:

Whenever self 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. explicitly.

[…]

While this proposal opens up implicit self in situations where we can be reasonably sure that we will not cause a reference cycle, there are other cases where implicit self 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.

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:

• Dealing With Weak in Closure-based Delegation
• Stop the weak-strong Swift Dance

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.