On 14 November 2017 at 21:02, David Hart <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
