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 < [email protected]> 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* > > [email protected] > > ajohnson on Slack > > > > *From: *<[email protected]> on behalf of Anton Zhilin < > [email protected]> > *Date: *Saturday, March 4, 2017 at 1:45 AM > *To: *"[email protected]" <[email protected]> > *Cc: *Alex Johnson <[email protected]> > *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 < > [email protected]>: > > 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
