[swift-evolution] A compiler option to warn if a closure captures a strong reference to a class instance?

Matthew Johnson matthew at anandabits.com
Mon Feb 20 11:22:31 CST 2017

> On Feb 20, 2017, at 11:09 AM, David Hart via swift-evolution <swift-evolution at swift.org> wrote:
>> On 20 Feb 2017, at 12:22, Lauri Lehmijoki via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 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). 
> I used RxSwift extensively and that’s not what I have experienced. I have streams with lifetimes dependent on the lifetime of the DisposeBag 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.
>> 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.
>> So, I'd like to ask you two things:
>> A) By default, why the Swift closure captures values strongly?
> If the default were weak, it would litter closures with ?
> If the default were unowned, your programs would crash without you understanding.
> I think its a sensible default.

I shard a proposal draft yesterday that introduces what I have called guarded closures and allows APIs to require callers to use a guarded closure.  I really think this is a promising direction to improving our story around reference capture by closures.

>> B) Should we add a compiler option that, when turned on, would emit a warning if a closure strongly captures a class instance?
> 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.

Agree.  We should not get a warning or error here.  We should improve the language so it is a lot harder to make this kind of mistake.

>> Regards
>> Lauri
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto: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/20170220/bfd5ba56/attachment.html>

More information about the swift-evolution mailing list