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

@walmartlabs.com > > ajohnson on Slack > > > > *From: *<antony.zhi...@gmail.com> on behalf of Anton Zhilin < > antonyzhi...@gmail.com> > *Date: *Saturday, March 4, 2017 at 1:45 AM > *To: *"swift-evolution@swift.org" <swift-evolution@swift.org>

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

Is callback an autoclosure, or just a regular argument? -Kenny > On Mar 3, 2017, at 1:14 PM, Alex Johnson via swift-evolution > wrote: > > Hi list members, > > During code review today, I noticed a really subtle memory leak that looked > like: > >

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

lin <antonyzhi...@gmail.com> Date: Saturday, March 4, 2017 at 1:45 AM To: "swift-evolution@swift.org" <swift-evolution@swift.org> Cc: Alex Johnson <ajohn...@walmartlabs.com> Subject: Re: [swift-evolution] Should explicit `self.` be required when providing method as c

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

> On 3 Mar 2017, at 22:14, Alex Johnson via swift-evolution > wrote: > > Hi list members, > > During code review today, I noticed a really subtle memory leak that looked > like: > > self.relatedObject = RelatedObject(callback: relatedObjectDidFinish) > >

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

> On Mar 5, 2017, at 11:12 AM, Daniel Leping via swift-evolution > 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

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

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. What I want to stress is this particular case with self autocapturing which gives a headache to me a lot. Any thoughts? On Sun, 5 Mar 2017 at

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

[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@swift.org> wrote: > I think we can stretch it even further. Have an idea in mind. > > Automatically

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

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

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

Is callback an autoclosure, or just a regular argument? -Kenny > On Mar 3, 2017, at 1:14 PM, Alex Johnson via swift-evolution > wrote: > > Hi list members, > > During code review today, I noticed a really subtle memory leak that looked > like: > >

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

Sent from my iPad > On Mar 4, 2017, at 11:35 AM, Charles Srstka via swift-evolution > wrote: > >> On Mar 4, 2017, at 1:09 AM, David Hart via swift-evolution >> wrote: >> >> I encountered this precise memory leak in my code a few days

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

> On Mar 4, 2017, at 1:09 AM, David Hart via swift-evolution > wrote: > > I encountered this precise memory leak in my code a few days ago, so I > sympathize. A second solution would be to drop function references. I think a > core team member suggested it on

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

I disagree with dropping function references in general, but I do agree with limiting partially applied method references. In @escaping arguments, adding self. won’t add enough evidence that it actually creates a closure with capture. Even in non-escaping context, I find plain method references

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

I encountered this precise memory leak in my code a few days ago, so I sympathize. A second solution would be to drop function references. I think a core team member suggested it on another thread. > On 3 Mar 2017, at 22:27, Josh Parmenter via swift-evolution >

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

Honestly, I think this is one of the rougher parts of the language to see problems in. In my opinion, anything that can be done to either warn of retain cycles or enforce a better practice in this would be valuable. Josh On Mar 3, 2017, at 1:14 PM, Alex Johnson via swift-evolution

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

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