<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 20, 2017, at 9:09 AM, David Hart 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 20 Feb 2017, at 12:22, Lauri Lehmijoki 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=""><div dir="ltr" class="">I'm developing an application where we use RxSwift heavily. RxSwift is a stream library. Consequently, closures that we pass to its combinators often live infinitely (this is because one can use RxSwift to represent infinitely long sequences in time). </div></div></blockquote><div class=""><br class=""></div><div class="">I used RxSwift extensively and that’s not what I have experienced. I have streams with lifetimes dependent on the lifetime of the <b class="">DisposeBag</b> they are added to, which is itself linked to the lifetime of the current View Controller or View Model. And that very closely resembles the way closures work in the Cocoa APIs (UIAlertAction handlers, etc…). I don’t think RxSwift is at odds.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Closures with infinite lifespan have implications for the question "what is the best reference capture mode for closures". My experience is that in RxSwift applications, the current default (strong) is almost always suboptimal. It leads to difficult-to-detect memory leaks and introduces a "gotcha" factor to programmers who are new to Swift. I'd prefer the default to be weak capture.<div class=""><br class=""></div><div class="">So, I'd like to ask you two things:</div><div class=""><br class=""></div><div class="">A) By default, why the Swift closure captures values strongly?</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">If the default were <b class="">weak</b>, it would litter closures with <b class="">?</b></div><div class="">If the default were <b class="">unowned</b>, your programs would crash without you understanding.</div><div class="">I think its a sensible default.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="">B) Should we add a compiler option that, when turned on, would emit a warning if a closure strongly captures a class instance?</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Perhaps we can improve the situation, but I’m not sure that is the solution. Sometimes I want my references to be strongly captured and I don’t want a warning to pollute by build output.</div><br class=""></div></div></div></blockquote><div><br class=""></div><div>In general, these should not be warnings as Swift tries to avoid effective language dialects through warnings. But, this would be an awesome lint rule!</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="">Regards</div><div class="">Lauri</div></div></div>
_______________________________________________<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" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></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=""></body></html>