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

[Alex Johnson]

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

From: <antony.zhilin at gmail.com> on behalf of Anton Zhilin <antonyzhilin at gmail.com>
Date: Saturday, March 4, 2017 at 1:45 AM
To: "swift-evolution at swift.org" <swift-evolution at swift.org>
Cc: Alex Johnson <AJohnson at 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 at swift.org<mailto:swift-evolution at 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.
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170306/f3ae8230/attachment.html>