> On Mar 5, 2017, at 11:12 AM, Daniel Leping via swift-evolution > <swift-evolution@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 <wh1pch...@gmail.com > <mailto:wh1pch...@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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 >> ajohn...@walmartlabs.com <mailto:ajohn...@walmartlabs.com> >> ajohnson on Slack >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <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
