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
