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

[Kenny Leung via swift-evolution]

I’m back to writing Objective-C again, and it is actually warning you about 
possible reference cycles in your closures. I’m for Swift doing the same.

-Kenny

> On Feb 20, 2017, at 3:22 AM, Lauri Lehmijoki via swift-evolution 
>  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). 
> 
> 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?
> B) Should we add a compiler option that, when turned on, would emit a warning 
> if a closure strongly captures a class instance?
> 
> Regards
> Lauri
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Michael Ilseman via swift-evolution]

> On Feb 20, 2017, at 9:09 AM, David Hart via swift-evolution 
>  wrote:
> 
> 
>> On 20 Feb 2017, at 12:22, Lauri Lehmijoki via swift-evolution 
>> > 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.
> 
>> 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.
> 

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!

>> Regards
>> Lauri
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Robert Widmann via swift-evolution]

It's important to note that strong captures by default are correct and not the 
issue here.  It is reference cycles that are the problem.  This feature has 
been requested before, and SR-1807 has been filed for it.  

(For what it's worth, I started working on this a while ago, and a branch 
tracking this is here: 
https://github.com/apple/swift/compare/master...CodaFi:hammer-and-cycle).

~Robert Widmann

2017/02/20 6:22、Lauri Lehmijoki via swift-evolution  
のメッセージ:

> 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). 
> 
> 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?
> B) Should we add a compiler option that, when turned on, would emit a warning 
> if a closure strongly captures a class instance?
> 
> Regards
> Lauri
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Anton Mironov via swift-evolution]

Hi. I’ve come to this issue too.
I thought that current Swift memory model is good enough to solve this in the 
other way. I've put self (aka ExecutionContext) as an argument to 
map/filter/etc. This looked like I'm binding execution to the specified 
context. It might sound odd, but it actually fits nicely into some kind of 
actor model. It opened such possibilities as automatic cancellation of async 
execution if there is no context that will use results of the execution.
Ended up developing a library that incorporates this idea AsyncNinja 
 sometimes looks even better then 
RxSwift . I 
also wrote an article 

 that shows advantages of the approach.
Please tell me if it makes sense for you.

Thanks,
Anton Mironov

> On Feb 20, 2017, at 1:22 PM, Lauri Lehmijoki via swift-evolution 
>  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). 
> 
> 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?
> B) Should we add a compiler option that, when turned on, would emit a warning 
> if a closure strongly captures a class instance?
> 
> Regards
> Lauri
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> On Feb 20, 2017, at 11:09 AM, David Hart via swift-evolution 
>  wrote:
> 
> 
>> On 20 Feb 2017, at 12:22, Lauri Lehmijoki via swift-evolution 
>> > 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@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Hart via swift-evolution]

> On 20 Feb 2017, at 12:22, Lauri Lehmijoki via swift-evolution 
>  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.

> 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.

> Regards
> Lauri
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Lauri Lehmijoki via swift-evolution]

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).

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

Regards
Lauri
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution