[swift-evolution] Add something like [unowned self] syntax for passing instance methods into closure parameters without creating retain cycles

[Benjamin Spratling]

Nick, I like where you’re headed with the instance-methods-as-closures idea.  Here’s where I’m headed with it:

Closures are too often used to write the contents of what should be another function, producing code similar to the “pyramid of doom” avoided by guard.  I now generally write as little code as possible in a closure, and use it merely to dispatch out to a private function as quickly as possible.  This means I really do want classes to reference their own functions.  I look at closures more as providing the captured scope as the "void* context" that goes along with an old C function reference, as opposed to being the scope in which the code should be written.

I loved the “get a closure to implicit self using nothing but the function name” feature of Swift, but after running over a dead line by spending 1.5 days with 3 other developers trying to find a retain cycle caused by its use, we added it to our list of reasons to not merge code, hereafter referred to as “the list".  This from a guy who used to write flawless manual retain/release code, back in the day.

Incidentally, we also put “unowned" on "the list".  We always use “weak” instead.  The bottom line is unowned CAN crash, and weak can’t.  There is no way to know if a call to unowned will crash or not.  So we prefer to write code that can’t crash. (No, we don’t force-unwrap weak optionals, “!” is on "the list”, and we nicknamed it the “Russian Roulette operator”)  So instead of “something like [unowned self] syntax...”, I’m suggesting “something like [weak self] syntax..."

So I’d prefer something like “weakself?.functionName” to produce a closure which wraps a weak-self reference and a call to the given method if self isn’t nil.  This seems like a trivial task for the compiler when return types are Void or Optional.  Given the expectations of optional chaining, and the zeroing behavior of any not-owned relationship, I’m not sure it makes sense to demand a non-optional return type for a call to a parent.  So I don’t think such a feature even needs to worry about what if the expected return type isn’t optional.

I’d be happy to see any of the following syntaxes:

weakself.functionName
weakself?.functionName
?functionName
welf.functionName
self?.functionName
weak(self)?.functionName

Obviously, one work around is to declare a protocol, and pass self, letting the receiving class store a weak reference.  But declaring protocols for every single closure reference is a bit tedious.  Literally just the back and forth on naming them is a waste of time.  And there’s the running joke that we’d just tack “able” on the end of the method name.

Another work around is to create several generic classes which generate closures which weakly capture self and an unapplied method reference, and overloaded functions or operators to provide the correct class.  Unfortunately, this still requires writing “self” explicitly, and also explicitly writing the type of self to obtain an unapplied method reference.

Given our experience, I would consider giving a warning when an implicit-self closure goes into an @escaping context.

	class SomeClass {
	var someFunction:(()->())?
	func setup() {
		prepare(closure: trigger)	//this should probably be a warning
	}
	func prepare(closure:@escaping()->()) {
		someFunction = closure
	}
	func trigger() {
	}
	}

Self is already required when used inside an closure, for exactly this reason.
Perhaps we should require the developer to write explicit “self” or “self?” to indicate strong or weak capture of self.
	prepare(closure: self.trigger)	//ok, strong self
	prepare(closure: self?.trigger)	//ok, weak self
Or if they would like to use unowned, 
	prepare(closure: RussianRoulette(self).trigger)	// ;-)

In the end, however, closures do occasionally capture non-instance-property scope, which would need to be adapted in the wrapping closure around the call to another method, so the number of no-adapting-needed methods may be quite low.  I expect given current priorities that this wouldn’t make it in to Swift 3.1.  But given the severity of the consequences and the simplicity of the implementation, I would hope it would make it by Swift 4.

-Ben Spratling