[swift-evolution] [Pitch] Improving capturing semantics of local functions

[David Hart]

> On 14 Nov 2017, at 20:41, Wallacy <wallacyf at gmail.com> wrote:
> 
> 
> 
> Em ter, 14 de nov de 2017 às 17:02, Mike Kluev via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> escreveu:
> On Mon, 13 Nov 2017 22:30:25 +0100 David Hart <david at hartbit.com <mailto:david at hartbit.com>> wrote:
> > On 13 Nov 2017, at 05:52, Slava Pestov <spestov at apple.com <mailto:spestov at apple.com>> wrote:
> >
> >> On Nov 12, 2017, at 8:11 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> >>
> >> By analogy with the current closure syntax, the capture list ought to go somewhere before the parameter list, in one of these slots:
> >>
> >> 1.   func fn<T>[foo, bar](param: T) throws -> T where T: Equatable { … }
> >> 2.   func fn[foo, bar]<T>(param: T) throws -> T where T: Equatable { … }
> >> 3.   func [foo, bar] fn<T>(param: T) throws -> T where T: Equatable { … }
> >> 4.   [foo, bar] func fn<T>(param: T) throws -> T where T: Equatable { … }
> >>
> >> Of these options, I actually think #4 reads best; 1 and 2 are very cluttered, and 3 just seems weird. But it seems like the one that would be easiest to misparse.
> >
> > Another option that reads nicely IMHO is
> >
> > func fn<T>(param: T) throws -> T where T : Equatable [foo, bar] { … }
> >
> > I think #4 is ambiguous with array literals unfortunately.
> 
> adding to the list of options:
> 
> 6. func fn<T>(param: T) throws -> T where T: Equatable [foo, bar] { … }
> 
> otherwise +1 to #1 and to the one in proposal. also see about #4 below.
> 
> plus, if 90%+ of use cases in practice would be [weak self] -- (the only examples shown in the proposals FTM) -- i would strongly consider this syntax sugar in addition to a generic notation:
> 
> weak func fn<T>(param: T) throws -> T where T: Equatable { … }
> 
> works with "unowned" as a bonus.
> 
> 
> weak func  to imply [weak self] is a good idea. 

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 doesn’t transpose well to local closures

On the other hand, the proposal attempts to resolve the problems mentioned in the Motivation section by introducing as little syntax as possible. And the little it does (capture lists) is no similar to closures that increased complexity tax is fairly low.

> weak func foo() {
>   self?.bar();
> }
> 
> unowned func foo() {
>   self.bar();
> }
> 
> Maybe this to:
> 
> onChange = weak { self?.bar() }
> 
> But we still have the problem using capture list.
> 
> And to avoid inconsistencies, I would leave the same way as the proposal.
> 
>  func local() { [weak self] in
>             self?.bar()
>         }
> 
> There's no perfect solution. And in this works fine today.
> 
>  
> if implement this sugar than some variation of #4 looks appealing to have these capture things close.
> 
> Mike
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171114/48f3a273/attachment.html>