[swift-evolution] Should explicit `self.` be required when providing method as closure?

[Matthew Johnson]

> On Mar 5, 2017, at 11:12 AM, Daniel Leping via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I'm not proposing syntax right now. Rather approach. Should we make ANY capturing explicit? I don't know. Maybe someone has a stronger opinion here.

I think that would be way too verbose.  Perhaps you mean all *reference* captures in closures that may live beyond the stack frame they are declared in?  That would be more reasonable these are the cases where problems arise.

> 
> What I want to stress is this particular case with self autocapturing which gives a headache to me a lot.
> 
> Any thoughts?

I’ve been working on a proposal to introduce guarded closures.  I plan to work on a new draft later this afternoon which will cover my latest thoughts on how to best address this problem.  You can find an earlier draft and discussion here: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032478.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032478.html>.

> 
> 
> On Sun, 5 Mar 2017 at 18:42 Derrick Ho <wh1pch81n at gmail.com <mailto:wh1pch81n at gmail.com>> wrote:
> [owned self] is weird. [self] is probably better and is currently the way to explicitly capture a variable.
> 
> On Sun, Mar 5, 2017 at 6:35 AM Daniel Leping via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> I think we can stretch it even further. Have an idea in mind.
> 
> Automatically propagated self is actually a big issue. Most of the newbies do A LOT of mistakes with it. So I thought: what if we restrict it even further? Like have no access to self *unless* it's explicitly passed. It can be done the very same way we do with [weak self] or [unowned self]? What if we introduce [owned self] and remove automatic self propagation?
> 
> This way one will have to at least think twice which propagation to choose instead of default strong reference which is not that good in many cases. Most for me, actually.
> 
> If this idea gets any positive feedback and the issue is a headache not to me only I'll create a separate thread and/or proposal.
> 
> On Sat, 4 Mar 2017 at 21:55 Kenny Leung via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> Is callback an autoclosure, or just a regular argument?
> 
> -Kenny
> 
> 
>> On Mar 3, 2017, at 1:14 PM, Alex Johnson via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Hi list members,
>>  
>> During code review today, I noticed a really subtle memory leak that looked like:
>>  
>>     self.relatedObject = RelatedObject(callback: relatedObjectDidFinish)
>>  
>> Where `relatedObject` is a strong reference, `callback` is an escaping closure, and `relatedObjectDidFinish` is a method of `self`. From a memory management perspective, this code is equivalent to:
>>  
>>     self.relatedObject = RelatedObject(callback: { self.relatedObjectDidFinish })
>>  
>> In the second example, an explicit `self.` is required. It’s my understanding that this is to highlight that the closure keeps a strong reference to `self`. But, when passing a method, there is no such requirement, which makes it easier to accidentally create a retain cycle.
>>  
>> This made me wonder if an explicit `self.` should be required when passing a method as an escaping closure. And whether that would help in the same way that the explicit `self.` *inside* the closure is intended to.
>>  
>> If it were required, the code in the first example would be:
>>  
>>     self.relatedObject = RelatedObject(callback: self.relatedObjectDidFinish)
>>  
>> What do you think?
>>  
>> Alex Johnson
>> ajohnson at walmartlabs.com <mailto:ajohnson at walmartlabs.com>
>> ajohnson on Slack
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/20170305/9e5c2b07/attachment.html>