<div dir="ltr">It is good to explain that in the example I gave we do not have to declare self as weak (completion handlers do not need this), but it was declared this way to not retain the view controller (or view) while the user is already seeing something else on the screen.<div><br></div><div>-Van</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 9, 2016 at 3:04 AM, Vanderlei Martinelli <span dir="ltr">&lt;<a href="mailto:vmartinelli@alecrim.com" target="_blank">vmartinelli@alecrim.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Particularly I think the strong/weak dance, after understood and properly applied, is a benefit and not a bad thing.<br><div><br></div><div>We can write things like:</div><div><br></div><div><font face="monospace, monospace">doSomeLongRunningTaskThatCannotBeCancelled { [weak self] someText in</font></div><div><font face="monospace, monospace">    self?.someLabel.text = someText</font></div><div><font face="monospace, monospace">}</font></div><div><font face="monospace, monospace"><br></font></div><div>This is a very common case in Cocoa [Touch], I think. Using GC how could we say: “hey, if the result comes in and I&#39;m no longer here, just ignore it, okay?”</div><div><br></div><div>I really like that RC and ARC are alive in Swift. Perhaps in the future we have something better, yet I would still like to be able to write code like the above. About GC: I do not know any good reasons to bring it to Swift.</div><div><br></div><div>-Van</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Tue, Feb 9, 2016 at 2:54 AM, Paul Ossenbruggen via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div style="word-wrap:break-word"><span><div><div><blockquote type="cite"><div><br>On Feb 8, 2016, at 1:00 PM, Chris Lattner via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br><div><blockquote type="cite"><div><div style="word-wrap:break-word"><div><ul><li><br>the closure capture syntax uses up an unreasonable amount of mindshare just because of [weak self]</li></ul></div></div></div></blockquote><div><br></div><div>I think that this specific point is solvable in others ways, but I’ll interpret this bullet as saying that you don’t want to worry about weak/unowned pointers.  I completely agree that we strive to provide a simple programming model, and I can see how &quot;not having to think about memory management&quot; seems appealing.</div><br></div></blockquote></div></div></span>I actually like RC, and don’t find it particularly problematic except in this one case…the closure case. If we could solve this one problem then I think the rest of it is fine. I don’t mind remembering to put a weak reference in for back pointers etc. The benefits of RC are great, and the introduction of ARC was a great mental burden lifted of developer’s minds. Just trying to explain and remember all the tricky rules around the closure capture would be nice to solve and would love to discuss that rather than garbage collection. <div><br></div><div>- Paul<br><div><br></div></div></div><br></div></div><span class="">_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div>