[swift-evolution] A shortcut for weakly referencing functions

[James Richard]

I run into this a lot and love this idea.

> 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