<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I am very sure this is covered elsewhere, could someone point me to a discussion of why we can’t automate the removal of self cycles for closures. Is it because it essentially means that we need a garbage collector? This seems like one of the biggest stumbling blocks for new developers and even experienced developers of iOS. ARC was brilliant in that it eliminated 95% writing code to deal with memory issues, but for this one. What about a solution that just solved this one problem with closures and not a general solution that solved all memory cycles? Is that feasible? The strong and weak is pretty easy to understand everywhere else except the closure case, I know lots of people who don’t fully understand when you need to use weakSelf and strongSelf etc. Anyway, i am sure this has been discussed in depth just want to understand all the issues. Also, this may not be strictly a swift topic. <div class=""><br class=""></div><div class=""><div class=""><div><blockquote type="cite" class=""><div class="">On Jan 23, 2016, at 9:38 AM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 23, 2016, at 1:26 AM, Marc Knaup <<a href="mailto:marc@knaup.koeln" class="">marc@knaup.koeln</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Is the self requirement when using <font face="monospace, monospace" class="">[self]</font> capture still necessary once the limitations outlined by Chris Lattner are solved?<div class="">Or does this change still have to go through Swift Evolution?<br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">Once we have [self] in closures, I think it is obvious that the "self.” requirement would be disabled for any closure that uses it.</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Dec 18, 2015 at 1:21 AM, Chris Lattner via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br class="">
<br class="">
-Chris<br class="">
<div class="HOEnZb"><div class="h5"><br class="">
> On Dec 17, 2015, at 2:20 PM, Rudolf Adamkovic via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">
><br class="">
> +1<br class="">
><br class="">
> 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".<br class="">
><br class="">
> R+<br class="">
><br class="">
> Sent from my iPhone<br class="">
><br class="">
>> On 16 Dec 2015, at 00:02, Greg Parker via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">
>><br class="">
>> 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.<br class="">
>><br class="">
>> I wrote code this weekend that looked something like this:<br class="">
>><br class="">
>> data = ...<br class="">
>> running = true<br class="">
>> delegate.notifyBegin(data)<br class="">
>><br class="">
>> dispatch_async(queue) {<br class="">
>> self.processData(self.data)<br class="">
>> self.running = false<br class="">
>> self.delegate.notifyEnd(self.data)<br class="">
>> }<br class="">
>><br class="">
>> 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.<br class="">
>><br class="">
>> The proposal would allow the same code to be written like this:<br class="">
>><br class="">
>> data = ...<br class="">
>> running = true<br class="">
>> delegate.notifyBegin(data)<br class="">
>><br class="">
>> dispatch_async(queue) {<br class="">
>> [strong self] in<br class="">
>> processData(data)<br class="">
>> running = false<br class="">
>> delegate.notifyEnd(data)<br class="">
>> }<br class="">
>><br class="">
>> Advantages:<br class="">
>> * The dispatch'ed code looks like the non-dispatched code.<br class="">
>> * The capture of `self` is still obvious.<br class="">
>> * The code's action is clearer without the `self` noise.<br class="">
>><br class="">
>> Disadvantages:<br class="">
>> * 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.<br class="">
>><br class="">
>><br class="">
>> 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.<br class="">
>><br class="">
>><br class="">
>> --<br class="">
>> Greg Parker <a href="mailto:gparker@apple.com" class="">gparker@apple.com</a> Runtime Wrangler<br class="">
>><br class="">
>><br class="">
>> _______________________________________________<br class="">
>> swift-evolution mailing list<br class="">
>> <a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
> _______________________________________________<br class="">
> swift-evolution mailing list<br class="">
> <a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></body></html>