> On Oct 25, 2017, at 4:21 PM, David Hart <[email protected]> wrote:
>> On 25 Oct 2017, at 19:01, John McCall <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>> On Oct 25, 2017, at 7:41 AM, David Hart via swift-evolution
>>> <[email protected] <mailto:[email protected]>> 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
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
