Re: [swift-evolution] Should explicit `self.` be required when providing method as closure?

[Daniel Leping via swift-evolution]

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*
>
> ajohn...@walmartlabs.com
>
> ajohnson on Slack
>
>
>
> *From: *<antony.zhi...@gmail.com> on behalf of Anton Zhilin <
> antonyzhi...@gmail.com>
> *Date: *Saturday, March 4, 2017 at 1:45 AM
> *To: *"swift-evolution@swift.org" <swift-evolution@swift.org>
> *Cc: *Alex Johnson <ajohn...@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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Should explicit `self.` be required when providing method as closure?

[Kenny Leung via swift-evolution]

Is callback an autoclosure, or just a regular argument?

-Kenny


> On Mar 3, 2017, at 1:14 PM, Alex Johnson via swift-evolution 
>  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
> ajohn...@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

Re: [swift-evolution] Should explicit `self.` be required when providing method as closure?

[Alex Johnson via swift-evolution]

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
ajohn...@walmartlabs.com<mailto:ajohn...@walmartlabs.com>
ajohnson on Slack

From: <antony.zhi...@gmail.com> on behalf of Anton Zhilin 
<antonyzhi...@gmail.com>
Date: Saturday, March 4, 2017 at 1:45 AM
To: "swift-evolution@swift.org" <swift-evolution@swift.org>
Cc: Alex Johnson <ajohn...@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.
​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Should explicit `self.` be required when providing method as closure?

[Karl Wagner via swift-evolution]

> On 3 Mar 2017, at 22:14, Alex Johnson via swift-evolution 
>  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
> ajohn...@walmartlabs.com 
> ajohnson on Slack
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 


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

Re: [swift-evolution] Should explicit `self.` be required when providing method as closure?

[Matthew Johnson via swift-evolution]

> On Mar 5, 2017, at 11:12 AM, Daniel Leping via swift-evolution 
>  wrote:
> 
> 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 Sun, 5 Mar 2017 at 18:42 Derrick Ho  > 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 
> > 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 
> > wrote:
> Is callback an autoclosure, or just a regular argument?
> 
> -Kenny
> 
> 
>> On Mar 3, 2017, at 1:14 PM, Alex Johnson via swift-evolution 
>> > 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
>> ajohn...@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 
> 
> ___
> 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

Re: [swift-evolution] Should explicit `self.` be required when providing method as closure?

[Daniel Leping via swift-evolution]

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

Re: [swift-evolution] Should explicit `self.` be required when providing method as closure?

[Derrick Ho via swift-evolution]

[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*
> ajohn...@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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Should explicit `self.` be required when providing method as closure?

[Daniel Leping via swift-evolution]

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*
> ajohn...@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

Re: [swift-evolution] Should explicit `self.` be required when providing method as closure?

[Kenny Leung via swift-evolution]

Is callback an autoclosure, or just a regular argument?

-Kenny


> On Mar 3, 2017, at 1:14 PM, Alex Johnson via swift-evolution 
>  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
> ajohn...@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

Re: [swift-evolution] Should explicit `self.` be required when providing method as closure?

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Mar 4, 2017, at 11:35 AM, Charles Srstka via swift-evolution 
>  wrote:
> 
>> On Mar 4, 2017, at 1:09 AM, David Hart via swift-evolution 
>>  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.
> 
> 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.

> 
> Charles
> 
> ___
> 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

Re: [swift-evolution] Should explicit `self.` be required when providing method as closure?

[Charles Srstka via swift-evolution]

> On Mar 4, 2017, at 1:09 AM, David Hart via swift-evolution 
>  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.

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

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

Re: [swift-evolution] Should explicit `self.` be required when providing method as closure?

[Anton Zhilin via swift-evolution]

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?
}
}

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

Re: [swift-evolution] Should explicit `self.` be required when providing method as closure?

[David Hart via swift-evolution]

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 
>  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 
> > 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
> ajohn...@walmartlabs.com
> ajohnson on Slack
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> 
> Joshua Parmenter | Engineering Lead, Apple Technologies
> 
> T 248 777 
> C 206 437 1551
> F 248 616 1980
> 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

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

Re: [swift-evolution] Should explicit `self.` be required when providing method as closure?

[Josh Parmenter via swift-evolution]

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 
> 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
ajohn...@walmartlabs.com
ajohnson on Slack
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution



Joshua Parmenter | Engineering Lead, Apple Technologies

T 248 777 
C 206 437 1551
F 248 616 1980
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

[swift-evolution] Should explicit `self.` be required when providing method as closure?

[Alex Johnson via swift-evolution]

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
ajohn...@walmartlabs.com
ajohnson on Slack
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution