> On Oct 25, 2017, at 4:21 PM, David Hart <da...@hartbit.com> wrote: >> On 25 Oct 2017, at 19:01, John McCall <rjmcc...@apple.com >> <mailto: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?
You could leave the "in" off, but it's only a little weird to have it, and the inconsistency would probably be worse. John. > > 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 >>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution