[swift-evolution] [Pitch] Improving capturing semantics of local functions
Mike Kluev
mike.kluev at gmail.com
Tue Nov 14 15:36:53 CST 2017
On 14 November 2017 at 21:02, David Hart <david at hartbit.com> wrote:
>
>
> I’d be very hesitant to introduce this syntax:
>
>
> - it’s new syntax, so it comes with a complexity tax (it isn’t
> naturally obvious what it means for a func to be weak)
> - it’s only sugar for the capture of self
>
> it might cover well over 90% of use cases (by my "pessimistic"
estimate)... if someone has a quick way to scan and analyse, say, github
swift sources we may even know that current percentage number of real life
usage.
>
> - it doesn’t transpose well to local closures
>
>
the last one - maybe not. follow me:
let closure = { [weak self, bar] in ... }
which today can be written as:
let closure = { [weak self, bar] () -> Int in ... } // full form
or as:
let closure: () -> Int = { [weak self, bar] in ... } // full form
which allows this change:
let closure: [weak self, bar] () -> Int = { ... } // full alt form
or in alternative form:
let closure: weak () -> Int = { [bar] in ... } // short hand form
same can be with functions:
func fn() -> Int { [weak self, bar] in ... } // full form
weak func fn() -> Int { [bar] in ... } // short hand form
the two capture attributes will in practice be "close" to each other:
weak func fn() {
[bar] in
....
}
and in majority of cases there will be only weak self:
weak func fn() {
....
}
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171114/886f4c47/attachment.html>
More information about the swift-evolution
mailing list