[swift-evolution] A shortcut for weakly referencing functions

[Radosław Pietruszewski]

Thanks for chiming in, Joe, and apologies for not replying promptly!

> "self.doSomething" method applications are also the only place where we directly capture an object into a closure without explicit closure syntax, which is where much of the surprise about memory leaks comes from.

Ohhh. So that’s interesting. Makes total sense, but from a programmer’s perspective I just thought of `self.doSomething` as nothing more than a function reference. But, if I understand correctly, it’s actually equivalent to `{ [self] in Foo.doSomething(self)($0) }`, correct?

> Even when strong references are desired, it's arguable that { self.doSomething($0) } is still preferable, since it's more obviously capturing `self`, and that the 'self.doSomething' shorthand is a misfeature.

Hm. Not having the shortcut would suck a bit, but it’s hard to argue with the fact that it’s much clearer you’re doing something potentially dangerous.

What about this, then: rip out the `self.doSomething` method applications, but have a shortcut, like the ones I proposed, that’s more explicit about the method capture:

#strong(self.doSomething) // <— currently just self.doSomething
#weak(self.doSomething)
#unowned(self.doSomething)

The balance of closure syntaxes is zero ;) but the Misfeature Shorthand is now clearer, and forming weak/unowned-self is easier and less noisy.

— Radek

> On 01 Apr 2016, at 19:35, Joe Groff <jgroff at apple.com> wrote:
> 
> As we briefly discussed on Twitter, I feel like Swift already has too much closure syntax as it is. { [unowned self] self.doSomething($0) } is definitely more text than self.doSomething, but it's clear what it's doing. "self.doSomething" method applications are also the only place where we directly capture an object into a closure without explicit closure syntax, which is where much of the surprise about memory leaks comes from. Even when strong references are desired, it's arguable that { self.doSomething($0) } is still preferable, since it's more obviously capturing `self`, and that the 'self.doSomething' shorthand is a misfeature.
> 
> -Joe
> 
>> On Apr 1, 2016, at 8:09 AM, Radosław Pietruszewski via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Here’s a pattern I find myself doing quite often:
>> 
>> 1> class Child {
>> 2.     var onSomeEvent: () -> Void = { }
>> 3. }
>> 4> class Parent {
>> 5.     let child = Child()
>> 6.     init() {
>> 7.         child.onSomeEvent = doSomething
>> 8.     }
>> 9.     func doSomething() {
>> 10.     }
>> 11. }
>> 
>> I have some ownership hierarchy of classes (often controllers — view controllers — views), where I pass information from children up to parents using closures set by the parent.
>> 
>> I like this pattern because children classes don’t have to be tied to knowledge about their parents, and I don’t have to define delegate protocols. It’s very clean, and also very easy to set up.
>> 
>> The only problem is that there’s a strong danger of introducing reference cycles.
>> 
>> With class properties, you can quite easily see the potential for a reference cycle and mark references to parents with weak/unowned. And with `self` captures in closures, you’re reminded of memory management by having to be explicit about `self`. But when passing references from parents to children, there’s no way to mark the closure property as `weak` (and there’s no reminder of the danger).
>> 
>> * * *
>> 
>> Right now, every time I pass a closure down to children, I have to wrap my references like so:
>> 
>> 	{ [unowned self] self.doSomething($0) }
>> 
>> instead of a neat and simple function reference:
>> 
>> 	doSomething
>> 
>> I think it would be useful to have a shortcut syntax for creating weak and unowned references to functions, like so:
>> 
>> 	@unowned(doSomething)
>> 
>> or perhaps:
>> 
>> 	#unowned(self.doSomething)
>> 
>> * * *
>> 
>> An alternative would be the ability to mark closure properties as weak or unowned. Then I could, at the *child* level, say:
>> 
>> 	unowned let onSomeEvent: () -> Void
>> 
>> * * *
>> 
>> Does this make sense? What do you think?
>> 
>> — Radek
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>