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

[Jumhyn (Frederick Kellison-Linn)]

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:

@dabrahams

Close an existing hole in the reference cycle protection provided by this rule (pointed out by John Harper), by adding the rule that an escaping bound method or property of a class requires “ self. ” qualification:

class Y {
    func inc(x: Int) -> Int { return x + 1 }

    func escape1() -> (Int) -> Int { 
        return inc // error: escaping bound method 'inc' requires 'self.' to make capture semantics explicit.
    }

    func escape2() -> (Int) -> Int { 
        return self.inc // OK
    }
}

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!