[swift-evolution] Proposal: Allow `[strong self]` capture in closures and remove the `self` requirement therein

[Dennis Lysenko]

+1, this also solves one of the problems I brought forth with implicit
self, and it would be a sizeable step toward making that proposal fully
unnecessary.

On Thu, Dec 17, 2015, 7:21 PM Chris Lattner via swift-evolution <
swift-evolution at swift.org> wrote:

> FWIW, I’m also +1 on this proposal, but it should just be a capture list
> of [self], since all captures are strong by default.  This is also part of
> the intended design of capture lists.  The only reason we don’t do this
> already is that there are some implementation limitations (aka, hacks)
> around name lookup of “self" that need to be unraveled.
>
> -Chris
>
> > On Dec 17, 2015, at 2:20 PM, Rudolf Adamkovic via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > +1
> >
> > I've been writing a lot of experimental UIKit animation code past couple
> of days and spent most of my time adding and removing "self".
> >
> > R+
> >
> > Sent from my iPhone
> >
> >> On 16 Dec 2015, at 00:02, Greg Parker via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>
> >> Swift currently requires that `self` be used explicitly inside
> closures, to help avoid bugs from unintentional capture. This is annoying
> when a closure uses `self` a lot. Closures should be allowed to name
> `[strong self]` in their capture list and thereafter not be required to
> write `self` everywhere.
> >>
> >> I wrote code this weekend that looked something like this:
> >>
> >>   data = ...
> >>   running = true
> >>   delegate.notifyBegin(data)
> >>
> >>   dispatch_async(queue) {
> >>       self.processData(self.data)
> >>       self.running = false
> >>       self.delegate.notifyEnd(self.data)
> >>   }
> >>
> >> Note the asymmetry: the dispatched code needs to use `self` and the
> non-dispatched code does not. It is clear that the dispatched closure
> captures `self`, but it's annoying that it needed to be mentioned five
> different times. The noise gets worse with longer closures. The annoyance
> gets worse when moving code in and out of dispatches or other closures,
> with lots of editing required each time.
> >>
> >> The proposal would allow the same code to be written like this:
> >>
> >>   data = ...
> >>   running = true
> >>   delegate.notifyBegin(data)
> >>
> >>   dispatch_async(queue) {
> >>       [strong self] in
> >>       processData(data)
> >>       running = false
> >>       delegate.notifyEnd(data)
> >>   }
> >>
> >> Advantages:
> >> * The dispatch'ed code looks like the non-dispatched code.
> >> * The capture of `self` is still obvious.
> >> * The code's action is clearer without the `self` noise.
> >>
> >> Disadvantages:
> >> * The capture behavior of self's properties is less obvious. For
> example, neither closure above captured its own copy of `self.data`, but
> that behavior is not immediately visible in the second closure.
> >>
> >>
> >> What about [weak self] and [unowned self] ? I do not propose to change
> the `self` requirement for those closures. In the weak case it is
> critically important to know where `self` is accessed, because it could
> potentially become nil between any two accesses. Unowned self might be
> reasonable to change, but for simplicity I won't do so here.
> >>
> >>
> >> --
> >> Greg Parker     gparker at apple.com     Runtime Wrangler
> >>
> >>
> >> _______________________________________________
> >> swift-evolution mailing list
> >> swift-evolution at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151218/7b5ed285/attachment.html>