Re: [swift-evolution] Making capturing semantics of local functions explicit

> On 25. Oct 2017, at 13:41, David Hart via swift-evolution > 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

Re: [swift-evolution] Making capturing semantics of local functions explicit

Hi, > On 25 Oct 2017, at 6:01 pm, John McCall via swift-evolution > wrote: > >> On Oct 25, 2017, at 7:41 AM, David Hart via swift-evolution >> 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

Re: [swift-evolution] Making capturing semantics of local functions explicit

class A { func foo() -> ()->String { func local() -> String { [weak self] in return "foo \(self.i)" } return local } ... compares well with this... class A { func foo() -> ()->String { let local : () -> String = { [weak self] in

Re: [swift-evolution] Making capturing semantics of local functions explicit

i support this™ On Wed, Oct 25, 2017 at 6: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

Re: [swift-evolution] Making capturing semantics of local functions explicit

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

Re: [swift-evolution] Making capturing semantics of local functions explicit

> On Oct 25, 2017, at 4:21 PM, David Hart wrote: >> On 25 Oct 2017, at 19:01, John McCall > > wrote: >> >>> On Oct 25, 2017, at 7:41 AM, David Hart via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> I got bit again by a sneaky memory leak concerning

Re: [swift-evolution] Making capturing semantics of local functions explicit

> On 25 Oct 2017, at 19:01, John McCall wrote: > >> On Oct 25, 2017, at 7:41 AM, David Hart via swift-evolution >> 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 rem

Re: [swift-evolution] Making capturing semantics of local functions explicit

Does the compiler treat a nested function differently from a closure in any meaningful way? (I suppose they might have symbols emitted in the symbol table, whereas a closure assigned to a local variable wouldn't?) It definitely seems odd that you can write two functionally equivalent pieces of cod

Re: [swift-evolution] Making capturing semantics of local functions explicit

> On Oct 25, 2017, at 4:41 AM, David Hart via swift-evolution > 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

Re: [swift-evolution] Making capturing semantics of local functions explicit

> On Oct 25, 2017, at 7:41 AM, David Hart via swift-evolution > 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 poi

[swift-evolution] Making capturing semantics of local functions explicit

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: cl