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