Requiring explicit 'self.' for bound methods treated as @escaping closures

Recently, I have been extending my proposal and implementation for allowing implicit usage of self in escaping closures when self is captured explicitly to encompass @dabrahams suggestions in the pitch thread. I had a couple questions about the implementation approach for the idea regarding requiring self when passing a bound method as an escaping closure:

My initial approach was to investigate extending the existing diagnostics for passing non-escaping closures to escaping contexts, but after looking into that I found that this logic is buried in the CS logic for type conversions between escaping and non-escaping closures. I'm not familiar with this part of the compiler, so wanted to solicit feedback about what others thought might be the best way to approach this diagnostic.

A couple options occurred to me off the top of my head: the information of whether implicit self was used could (maybe?) be propagated down via the type system, with implicit self accesses yielding a non-escaping version of the method which requires "conversion" by adding explicit self, but that seems like it could be a misuse of the type system. However, if I'm analyzing the use sites outside of the CS, I'm unclear how I would be able to tell that the method is being used in an escaping context—is this information recoverable after all the types are solved for?

If anyone has other suggestions or ideas about how best to implement this diagnostic, I'd love to hear those as well! :slight_smile:

Terms of Service

Privacy Policy

Cookie Policy