Allow implicit self in escaping closures when self is explicitly captured

Evolution Pitches
19

Resurrecting this thread, because it's a great idea. I'd like to expand on the pitch, because we need a comprehensive answer to the problem of “self.” clutter and the overall ineffectiveness of the requirement to write it. I propose the following:

  • Start with Frederick's proposal.

  • Eliminate the need to even write “[self] in” when self is known to be a non-class type. The only purpose of the “self.” rule is to expose unintended reference cycles, which are extremely rare when self is not a class type. One place (chosen at random of course!) where this would make a big difference: even seeing “[self] in” is onerous for many real SwiftUI examples and is worse than a single “self.”.

  • 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
    }
}

What do you think?

23 Likes