> On 25 Oct 2017, at 19:01, John McCall <rjmcc...@apple.com> wrote: > >> On Oct 25, 2017, at 7:41 AM, David Hart via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> I got bit again by a sneaky memory leak concerning local functions and would >> like to discuss a small language change. I vaguely remember this being >> discussed in the past, but can’t find the thread (if anybody could point me >> to it, I’d appreciate it). Basically, here’s an example of the leak: >> >> class A { >> func foo() { >> func local() { >> bar() >> } >> >> methodWithEscapingClosure { [unowned self] _ in >> self.bar() >> local() // this leaks because local captures self >> } >> } >> >> func bar() { >> } >> } >> >> Its sneaky because local’s capturing of self is not obvious if you’ve >> trained your brain to watch out for calls prefixed with self. I would >> suggest having the compiler force users to make self capturing explicit, the >> same way it does for closures: > > I think this is a good idea. Ideally the proposal would also allow explicit > capture lists in local functions.
Ideally, yes. But the only sensible syntax I can come up for that seems odd in the context of functions: class A { func foo() { func local() -> Int { [weak self] in } } } Don’t you think? David. > John. > >> >> class A { >> func foo() { >> func local() { >> bar() // error: Call to method ‘bar' in function ‘local' >> requires explicit 'self.' to make capture semantics explicit >> } >> >> // ... >> } >> } >> >> What do you think? >> >> David. >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto: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