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

John McCall rjmccall at apple.com
Wed Oct 25 16:45:31 CDT 2017


> On Oct 25, 2017, at 4:21 PM, David Hart <david at hartbit.com> wrote:
>> On 25 Oct 2017, at 19:01, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote:
>> 
>>> On Oct 25, 2017, at 7:41 AM, David Hart via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171025/4405d2e2/attachment.html>


More information about the swift-evolution mailing list