<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=""><div class=""><div><blockquote type="cite" class=""><div class=""><br class="">On Feb 8, 2016, at 1:00 PM, 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=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><ul class="MailOutline"><li class=""><br class="Apple-interchange-newline">the closure capture syntax uses up an unreasonable amount of mindshare just because of [weak self]</li></ul></div></div></div></blockquote><div class=""><br class=""></div><div class="">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 "not having to think about memory management" seems appealing.</div><br class="Apple-interchange-newline"></div></blockquote></div></div>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 class=""><br class=""></div><div class="">- Paul<br class=""><div class=""><br class=""></div></div></body></html>