[swift-evolution] Making capturing semantics of local functions explicit
David Hart
david at hartbit.com
Wed Oct 25 15:21:25 CDT 2017
> On 25 Oct 2017, at 19:01, John McCall <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?
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171025/9ed84710/attachment.html>
More information about the swift-evolution
mailing list