I agree; I think the 'in' should be there. This should be fairly straight-forward to implement right? It's just alternative syntax over existing behavior. (thinking about the proposal now...)
On Wed, Oct 25, 2017 at 5:45 PM, John McCall via swift-evolution < swift-evolution@swift.org> wrote: > 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> wrote: > > On Oct 25, 2017, at 7:41 AM, David Hart via swift-evolution < > 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 > 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