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

[Stephen Celis]

I like the simple capture list of [self].

Stephen

On Thu, Dec 17, 2015 at 9:01 PM, Dennis Lysenko via swift-evolution <
swift-evolution at swift.org> wrote:

> +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
>>
>
> _______________________________________________
> 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/20151217/2ae15128/attachment.html>