[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