Should explicit `self.` be required when providing method as closure?


(Alex Johnson) #1

Hi list members,

During code review today, I noticed a really subtle memory leak that looked like:

    self.relatedObject = RelatedObject(callback: relatedObjectDidFinish)

Where `relatedObject` is a strong reference, `callback` is an escaping closure, and `relatedObjectDidFinish` is a method of `self`. From a memory management perspective, this code is equivalent to:

    self.relatedObject = RelatedObject(callback: { self.relatedObjectDidFinish })

In the second example, an explicit `self.` is required. It’s my understanding that this is to highlight that the closure keeps a strong reference to `self`. But, when passing a method, there is no such requirement, which makes it easier to accidentally create a retain cycle.

This made me wonder if an explicit `self.` should be required when passing a method as an escaping closure. And whether that would help in the same way that the explicit `self.` *inside* the closure is intended to.

If it were required, the code in the first example would be:

    self.relatedObject = RelatedObject(callback: self.relatedObjectDidFinish)

What do you think?

Alex Johnson
ajohnson@walmartlabs.com<mailto:ajohnson@walmartlabs.com>
ajohnson on Slack


Revisiting requiring explicit `self.` when passing a method as an escaping closure
(Josh Parmenter) #2

Honestly, I think this is one of the rougher parts of the language to see problems in. In my opinion, anything that can be done to either warn of retain cycles or enforce a better practice in this would be valuable.
Josh

···

On Mar 3, 2017, at 1:14 PM, Alex Johnson via swift-evolution <swift-evolution@swift.org<mailto:swift-evolution@swift.org>> wrote:

Hi list members,

During code review today, I noticed a really subtle memory leak that looked like:

    self.relatedObject = RelatedObject(callback: relatedObjectDidFinish)

Where `relatedObject` is a strong reference, `callback` is an escaping closure, and `relatedObjectDidFinish` is a method of `self`. From a memory management perspective, this code is equivalent to:

    self.relatedObject = RelatedObject(callback: { self.relatedObjectDidFinish })

In the second example, an explicit `self.` is required. It’s my understanding that this is to highlight that the closure keeps a strong reference to `self`. But, when passing a method, there is no such requirement, which makes it easier to accidentally create a retain cycle.

This made me wonder if an explicit `self.` should be required when passing a method as an escaping closure. And whether that would help in the same way that the explicit `self.` *inside* the closure is intended to.

If it were required, the code in the first example would be:

    self.relatedObject = RelatedObject(callback: self.relatedObjectDidFinish)

What do you think?

Alex Johnson
ajohnson@walmartlabs.com<mailto:ajohnson@walmartlabs.com>
ajohnson on Slack
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org<mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Joshua Parmenter | Engineering Lead, Apple Technologies

T 248 777 7777
C 206 437 1551
F 248 616 1980
www.vectorform.com<http://www.vectorform.com/>

Vectorform
2107 Elliott Ave Suite 303
Seattle, WA 98121 USA

Think Tank. Lab. Studio.
We invent digital products and experiences.

SEATTLE | DETROIT | NEW YORK | MUNICH | HYDERABAD


(Kenny Leung) #3

Is callback an autoclosure, or just a regular argument?

-Kenny

···

On Mar 3, 2017, at 1:14 PM, Alex Johnson via swift-evolution <swift-evolution@swift.org> wrote:

Hi list members,

During code review today, I noticed a really subtle memory leak that looked like:

    self.relatedObject = RelatedObject(callback: relatedObjectDidFinish)

Where `relatedObject` is a strong reference, `callback` is an escaping closure, and `relatedObjectDidFinish` is a method of `self`. From a memory management perspective, this code is equivalent to:

    self.relatedObject = RelatedObject(callback: { self.relatedObjectDidFinish })

In the second example, an explicit `self.` is required. It’s my understanding that this is to highlight that the closure keeps a strong reference to `self`. But, when passing a method, there is no such requirement, which makes it easier to accidentally create a retain cycle.

This made me wonder if an explicit `self.` should be required when passing a method as an escaping closure. And whether that would help in the same way that the explicit `self.` *inside* the closure is intended to.

If it were required, the code in the first example would be:

    self.relatedObject = RelatedObject(callback: self.relatedObjectDidFinish)

What do you think?

Alex Johnson
ajohnson@walmartlabs.com <mailto:ajohnson@walmartlabs.com>
ajohnson on Slack
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Kenny Leung) #4

Is callback an autoclosure, or just a regular argument?

-Kenny

···

On Mar 3, 2017, at 1:14 PM, Alex Johnson via swift-evolution <swift-evolution@swift.org> wrote:

Hi list members,

During code review today, I noticed a really subtle memory leak that looked like:

    self.relatedObject = RelatedObject(callback: relatedObjectDidFinish)

Where `relatedObject` is a strong reference, `callback` is an escaping closure, and `relatedObjectDidFinish` is a method of `self`. From a memory management perspective, this code is equivalent to:

    self.relatedObject = RelatedObject(callback: { self.relatedObjectDidFinish })

In the second example, an explicit `self.` is required. It’s my understanding that this is to highlight that the closure keeps a strong reference to `self`. But, when passing a method, there is no such requirement, which makes it easier to accidentally create a retain cycle.

This made me wonder if an explicit `self.` should be required when passing a method as an escaping closure. And whether that would help in the same way that the explicit `self.` *inside* the closure is intended to.

If it were required, the code in the first example would be:

    self.relatedObject = RelatedObject(callback: self.relatedObjectDidFinish)

What do you think?

Alex Johnson
ajohnson@walmartlabs.com <mailto:ajohnson@walmartlabs.com>
ajohnson on Slack
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Karl) #5

+1

If you wrote it with a trailing closure, you would need to use ‘self’, so I think it’s reasonable to require it when passing the function as an escaping closure as well:

self.relatedObject = RelatedObject { self.relatedObjectDidFinish() } // self required here

Similarly, it would be nice if we had this convenient syntax for unowned function references:

self.relatedObject = RelatedObject { [unowned self] in self.relatedObjectDidFinish() }

would become:

self.relatedObject = RelatedObject(callback: (unowned self).relatedObjectDidFinish)

- Karl

···

On 3 Mar 2017, at 22:14, Alex Johnson via swift-evolution <swift-evolution@swift.org> wrote:

Hi list members,

During code review today, I noticed a really subtle memory leak that looked like:

    self.relatedObject = RelatedObject(callback: relatedObjectDidFinish)

Where `relatedObject` is a strong reference, `callback` is an escaping closure, and `relatedObjectDidFinish` is a method of `self`. From a memory management perspective, this code is equivalent to:

    self.relatedObject = RelatedObject(callback: { self.relatedObjectDidFinish })

In the second example, an explicit `self.` is required. It’s my understanding that this is to highlight that the closure keeps a strong reference to `self`. But, when passing a method, there is no such requirement, which makes it easier to accidentally create a retain cycle.

This made me wonder if an explicit `self.` should be required when passing a method as an escaping closure. And whether that would help in the same way that the explicit `self.` *inside* the closure is intended to.

If it were required, the code in the first example would be:

    self.relatedObject = RelatedObject(callback: self.relatedObjectDidFinish)

What do you think?

Alex Johnson
ajohnson@walmartlabs.com <mailto:ajohnson@walmartlabs.com>
ajohnson on Slack
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Hart) #6

I encountered this precise memory leak in my code a few days ago, so I sympathize. A second solution would be to drop function references. I think a core team member suggested it on another thread.

···

On 3 Mar 2017, at 22:27, Josh Parmenter via swift-evolution <swift-evolution@swift.org> wrote:

Honestly, I think this is one of the rougher parts of the language to see problems in. In my opinion, anything that can be done to either warn of retain cycles or enforce a better practice in this would be valuable.
Josh

On Mar 3, 2017, at 1:14 PM, Alex Johnson via swift-evolution <swift-evolution@swift.org<mailto:swift-evolution@swift.org>> wrote:

Hi list members,

During code review today, I noticed a really subtle memory leak that looked like:

   self.relatedObject = RelatedObject(callback: relatedObjectDidFinish)

Where `relatedObject` is a strong reference, `callback` is an escaping closure, and `relatedObjectDidFinish` is a method of `self`. From a memory management perspective, this code is equivalent to:

   self.relatedObject = RelatedObject(callback: { self.relatedObjectDidFinish })

In the second example, an explicit `self.` is required. It’s my understanding that this is to highlight that the closure keeps a strong reference to `self`. But, when passing a method, there is no such requirement, which makes it easier to accidentally create a retain cycle.

This made me wonder if an explicit `self.` should be required when passing a method as an escaping closure. And whether that would help in the same way that the explicit `self.` *inside* the closure is intended to.

If it were required, the code in the first example would be:

   self.relatedObject = RelatedObject(callback: self.relatedObjectDidFinish)

What do you think?

Alex Johnson
ajohnson@walmartlabs.com<mailto:ajohnson@walmartlabs.com>
ajohnson on Slack
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org<mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Joshua Parmenter | Engineering Lead, Apple Technologies

T 248 777 7777
C 206 437 1551
F 248 616 1980
www.vectorform.com<http://www.vectorform.com/>

Vectorform
2107 Elliott Ave Suite 303
Seattle, WA 98121 USA

Think Tank. Lab. Studio.
We invent digital products and experiences.

SEATTLE | DETROIT | NEW YORK | MUNICH | HYDERABAD

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Daniel Leping) #7

I think we can stretch it even further. Have an idea in mind.

Automatically propagated self is actually a big issue. Most of the newbies
do A LOT of mistakes with it. So I thought: what if we restrict it even
further? Like have no access to self *unless* it's explicitly passed. It
can be done the very same way we do with [weak self] or [unowned self]?
What if we introduce [owned self] and remove automatic self propagation?

This way one will have to at least think twice which propagation to choose
instead of default strong reference which is not that good in many cases.
Most for me, actually.

If this idea gets any positive feedback and the issue is a headache not to
me only I'll create a separate thread and/or proposal.

···

On Sat, 4 Mar 2017 at 21:55 Kenny Leung via swift-evolution < swift-evolution@swift.org> wrote:

Is callback an autoclosure, or just a regular argument?

-Kenny

On Mar 3, 2017, at 1:14 PM, Alex Johnson via swift-evolution < > swift-evolution@swift.org> wrote:

Hi list members,

During code review today, I noticed a really subtle memory leak that
looked like:

    self.relatedObject = RelatedObject(callback: relatedObjectDidFinish)

Where `relatedObject` is a strong reference, `callback` is an escaping
closure, and `relatedObjectDidFinish` is a method of `self`. From a memory
management perspective, this code is equivalent to:

    self.relatedObject = RelatedObject(callback: {
self.relatedObjectDidFinish })

In the second example, an explicit `self.` is required. It’s my
understanding that this is to highlight that the closure keeps a strong
reference to `self`. But, when passing a method, there is no such
requirement, which makes it easier to accidentally create a retain cycle.

This made me wonder if an explicit `self.` should be required when passing
a method as an escaping closure. And whether that would help in the same
way that the explicit `self.` *inside* the closure is intended to.

If it were required, the code in the first example would be:

    self.relatedObject = RelatedObject(callback:
self.relatedObjectDidFinish)

What do you think?

*Alex Johnson*
ajohnson@walmartlabs.com
ajohnson on Slack
_______________________________________________
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


(Charles Srstka) #8

If I had to guess, I’d surmise that it's probably the single most common memory leak in Swift and modern Objective-C code. What I wish is that it were possible to get rid of implicit captures altogether—instead of just inserting [weak self] when you *don’t* want to capture something strongly, also require [strong self] when you do. Referencing self otherwise causes an error. We’d never get away with it now, though, with the source compatibility promise in place.

Charles

···

On Mar 4, 2017, at 1:09 AM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

I encountered this precise memory leak in my code a few days ago, so I sympathize. A second solution would be to drop function references. I think a core team member suggested it on another thread.


(Anton Zhilin) #9

I disagree with dropping function references in general, but I do agree
with limiting partially applied method references.

In @escaping arguments, adding self. won’t add enough evidence that it
actually creates a closure with capture.
Even in non-escaping context, I find plain method references odd:

func square(_ x: Int) -> Int { … }

(1...10).map(square) // totally ok with that
class SomeClass {
    func foo(_ x: Int) -> Int { … }

    func bar() {
        (1...10).map(foo) // what??
        (1...10).map(self.foo) // ok
        someControl.addHandler(self.foo) // should be error if @escaping?
    }
}

I encountered this precise memory leak in my code a few days ago, so I

sympathize. A second solution would be to drop function references. I think
a core team member suggested it on another thread.

···

2017-03-04 10:09 GMT+03:00 David Hart via swift-evolution < swift-evolution@swift.org>:


(Derrick Ho) #10

[owned self] is weird. [self] is probably better and is currently the way
to explicitly capture a variable.

···

On Sun, Mar 5, 2017 at 6:35 AM Daniel Leping via swift-evolution < swift-evolution@swift.org> wrote:

I think we can stretch it even further. Have an idea in mind.

Automatically propagated self is actually a big issue. Most of the newbies
do A LOT of mistakes with it. So I thought: what if we restrict it even
further? Like have no access to self *unless* it's explicitly passed. It
can be done the very same way we do with [weak self] or [unowned self]?
What if we introduce [owned self] and remove automatic self propagation?

This way one will have to at least think twice which propagation to choose
instead of default strong reference which is not that good in many cases.
Most for me, actually.

If this idea gets any positive feedback and the issue is a headache not to
me only I'll create a separate thread and/or proposal.

On Sat, 4 Mar 2017 at 21:55 Kenny Leung via swift-evolution < > swift-evolution@swift.org> wrote:

Is callback an autoclosure, or just a regular argument?

-Kenny

On Mar 3, 2017, at 1:14 PM, Alex Johnson via swift-evolution < > swift-evolution@swift.org> wrote:

Hi list members,

During code review today, I noticed a really subtle memory leak that
looked like:

    self.relatedObject = RelatedObject(callback: relatedObjectDidFinish)

Where `relatedObject` is a strong reference, `callback` is an escaping
closure, and `relatedObjectDidFinish` is a method of `self`. From a memory
management perspective, this code is equivalent to:

    self.relatedObject = RelatedObject(callback: {
self.relatedObjectDidFinish })

In the second example, an explicit `self.` is required. It’s my
understanding that this is to highlight that the closure keeps a strong
reference to `self`. But, when passing a method, there is no such
requirement, which makes it easier to accidentally create a retain cycle.

This made me wonder if an explicit `self.` should be required when passing
a method as an escaping closure. And whether that would help in the same
way that the explicit `self.` *inside* the closure is intended to.

If it were required, the code in the first example would be:

    self.relatedObject = RelatedObject(callback:
self.relatedObjectDidFinish)

What do you think?

*Alex Johnson*
ajohnson@walmartlabs.com
ajohnson on Slack
_______________________________________________
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


(Matthew Johnson) #11

I encountered this precise memory leak in my code a few days ago, so I sympathize. A second solution would be to drop function references. I think a core team member suggested it on another thread.

If I had to guess, I’d surmise that it's probably the single most common memory leak in Swift and modern Objective-C code. What I wish is that it were possible to get rid of implicit captures altogether—instead of just inserting [weak self] when you *don’t* want to capture something strongly, also require [strong self] when you do. Referencing self otherwise causes an error. We’d never get away with it now, though, with the source compatibility promise in place.

Have you seen my guarded closures proposal? I'm planning to update that to incorporate some additional ideas as soon as I have time. I'm hoping I can get to this soon and have it reviews for Swift 4. I think it would help address this problem without breaking compatibility.

···

Sent from my iPad

On Mar 4, 2017, at 11:35 AM, Charles Srstka via swift-evolution <swift-evolution@swift.org> wrote:

On Mar 4, 2017, at 1:09 AM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

Charles

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Daniel Leping) #12

I'm not proposing syntax right now. Rather approach. Should we make ANY
capturing explicit? I don't know. Maybe someone has a stronger opinion here.

What I want to stress is this particular case with self autocapturing which
gives a headache to me a lot.

Any thoughts?

···

On Sun, 5 Mar 2017 at 18:42 Derrick Ho <wh1pch81n@gmail.com> wrote:

[owned self] is weird. [self] is probably better and is currently the way
to explicitly capture a variable.

On Sun, Mar 5, 2017 at 6:35 AM Daniel Leping via swift-evolution < > swift-evolution@swift.org> wrote:

I think we can stretch it even further. Have an idea in mind.

Automatically propagated self is actually a big issue. Most of the newbies
do A LOT of mistakes with it. So I thought: what if we restrict it even
further? Like have no access to self *unless* it's explicitly passed. It
can be done the very same way we do with [weak self] or [unowned self]?
What if we introduce [owned self] and remove automatic self propagation?

This way one will have to at least think twice which propagation to choose
instead of default strong reference which is not that good in many cases.
Most for me, actually.

If this idea gets any positive feedback and the issue is a headache not to
me only I'll create a separate thread and/or proposal.

On Sat, 4 Mar 2017 at 21:55 Kenny Leung via swift-evolution < > swift-evolution@swift.org> wrote:

Is callback an autoclosure, or just a regular argument?

-Kenny

On Mar 3, 2017, at 1:14 PM, Alex Johnson via swift-evolution < > swift-evolution@swift.org> wrote:

Hi list members,

During code review today, I noticed a really subtle memory leak that
looked like:

    self.relatedObject = RelatedObject(callback: relatedObjectDidFinish)

Where `relatedObject` is a strong reference, `callback` is an escaping
closure, and `relatedObjectDidFinish` is a method of `self`. From a memory
management perspective, this code is equivalent to:

    self.relatedObject = RelatedObject(callback: {
self.relatedObjectDidFinish })

In the second example, an explicit `self.` is required. It’s my
understanding that this is to highlight that the closure keeps a strong
reference to `self`. But, when passing a method, there is no such
requirement, which makes it easier to accidentally create a retain cycle.

This made me wonder if an explicit `self.` should be required when passing
a method as an escaping closure. And whether that would help in the same
way that the explicit `self.` *inside* the closure is intended to.

If it were required, the code in the first example would be:

    self.relatedObject = RelatedObject(callback:
self.relatedObjectDidFinish)

What do you think?

*Alex Johnson*
ajohnson@walmartlabs.com
ajohnson on Slack
_______________________________________________
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


(Alex Johnson) #13

I’d be fine losing the ability to pass methods as escaping closures.

I wouldn’t like losing the ability to pass methods as non-escaping closures, because I find this pattern pretty useful:

  class MyViewController {
   var records: [Record]
   var visibleRecords: [Record] { return records.filter(isVisible) }

    func isVisible(_ record: Record) -> Bool {
        // some logic here, maybe using other properties of `self`
    }
  }

Alex Johnson
ajohnson@walmartlabs.com<mailto:ajohnson@walmartlabs.com>
ajohnson on Slack

···

From: <antony.zhilin@gmail.com> on behalf of Anton Zhilin <antonyzhilin@gmail.com>
Date: Saturday, March 4, 2017 at 1:45 AM
To: "swift-evolution@swift.org" <swift-evolution@swift.org>
Cc: Alex Johnson <AJohnson@walmartlabs.com>
Subject: Re: [swift-evolution] Should explicit `self.` be required when providing method as closure?

I disagree with dropping function references in general, but I do agree with limiting partially applied method references.

In @escaping arguments, adding self. won’t add enough evidence that it actually creates a closure with capture.
Even in non-escaping context, I find plain method references odd:

2017-03-04 10:09 GMT+03:00 David Hart via swift-evolution <swift-evolution@swift.org<mailto:swift-evolution@swift.org>>:
I encountered this precise memory leak in my code a few days ago, so I sympathize. A second solution would be to drop function references. I think a core team member suggested it on another thread.


(Matthew Johnson) #14

I'm not proposing syntax right now. Rather approach. Should we make ANY capturing explicit? I don't know. Maybe someone has a stronger opinion here.

I think that would be way too verbose. Perhaps you mean all *reference* captures in closures that may live beyond the stack frame they are declared in? That would be more reasonable these are the cases where problems arise.

What I want to stress is this particular case with self autocapturing which gives a headache to me a lot.

Any thoughts?

I’ve been working on a proposal to introduce guarded closures. I plan to work on a new draft later this afternoon which will cover my latest thoughts on how to best address this problem. You can find an earlier draft and discussion here: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032478.html.

···

On Mar 5, 2017, at 11:12 AM, Daniel Leping via swift-evolution <swift-evolution@swift.org> wrote:

On Sun, 5 Mar 2017 at 18:42 Derrick Ho <wh1pch81n@gmail.com <mailto:wh1pch81n@gmail.com>> wrote:
[owned self] is weird. [self] is probably better and is currently the way to explicitly capture a variable.

On Sun, Mar 5, 2017 at 6:35 AM Daniel Leping via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I think we can stretch it even further. Have an idea in mind.

Automatically propagated self is actually a big issue. Most of the newbies do A LOT of mistakes with it. So I thought: what if we restrict it even further? Like have no access to self *unless* it's explicitly passed. It can be done the very same way we do with [weak self] or [unowned self]? What if we introduce [owned self] and remove automatic self propagation?

This way one will have to at least think twice which propagation to choose instead of default strong reference which is not that good in many cases. Most for me, actually.

If this idea gets any positive feedback and the issue is a headache not to me only I'll create a separate thread and/or proposal.

On Sat, 4 Mar 2017 at 21:55 Kenny Leung via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Is callback an autoclosure, or just a regular argument?

-Kenny

On Mar 3, 2017, at 1:14 PM, Alex Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi list members,

During code review today, I noticed a really subtle memory leak that looked like:

    self.relatedObject = RelatedObject(callback: relatedObjectDidFinish)

Where `relatedObject` is a strong reference, `callback` is an escaping closure, and `relatedObjectDidFinish` is a method of `self`. From a memory management perspective, this code is equivalent to:

    self.relatedObject = RelatedObject(callback: { self.relatedObjectDidFinish })

In the second example, an explicit `self.` is required. It’s my understanding that this is to highlight that the closure keeps a strong reference to `self`. But, when passing a method, there is no such requirement, which makes it easier to accidentally create a retain cycle.

This made me wonder if an explicit `self.` should be required when passing a method as an escaping closure. And whether that would help in the same way that the explicit `self.` *inside* the closure is intended to.

If it were required, the code in the first example would be:

    self.relatedObject = RelatedObject(callback: self.relatedObjectDidFinish)

What do you think?

Alex Johnson
ajohnson@walmartlabs.com <mailto:ajohnson@walmartlabs.com>
ajohnson on Slack
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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


(Daniel Leping) #15

I think autocapturing can be restricted to non-escaping closures only. For
the escaping ones we should think of loosening capture-by-default feature.

Would works for you, Alex?

···

On Mon, 6 Mar 2017 at 19:35 Alex Johnson via swift-evolution < swift-evolution@swift.org> wrote:

I’d be fine losing the ability to pass methods as escaping closures.

I wouldn’t like losing the ability to pass methods as non-escaping
closures, because I find this pattern pretty useful:

  class MyViewController {

   var records: [Record]

   var visibleRecords: [Record] { return records.filter(isVisible) }

    func isVisible(_ record: Record) -> Bool {

        // some logic here, maybe using other properties of `self`

    }

  }

*Alex Johnson*

ajohnson@walmartlabs.com

ajohnson on Slack

*From: *<antony.zhilin@gmail.com> on behalf of Anton Zhilin <
antonyzhilin@gmail.com>
*Date: *Saturday, March 4, 2017 at 1:45 AM
*To: *"swift-evolution@swift.org" <swift-evolution@swift.org>
*Cc: *Alex Johnson <AJohnson@walmartlabs.com>
*Subject: *Re: [swift-evolution] Should explicit `self.` be required when
providing method as closure?

I disagree with dropping function references in general, but I do agree
with limiting partially applied method references.

In @escaping arguments, adding self. won’t add enough evidence that it
actually creates a closure with capture.
Even in non-escaping context, I find plain method references odd:

2017-03-04 10:09 GMT+03:00 David Hart via swift-evolution <
swift-evolution@swift.org>:

I encountered this precise memory leak in my code a few days ago, so I
sympathize. A second solution would be to drop function references. I think
a core team member suggested it on another thread.


_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution