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

Daniel Leping daniel at crossroadlabs.xyz
Mon Mar 6 17:43:52 CST 2017


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 at 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 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>:
>
> 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170306/fd90d95a/attachment.html>


More information about the swift-evolution mailing list