> On 14 Nov 2017, at 20:41, Wallacy <walla...@gmail.com> wrote:
>
>
>
> Em ter, 14 de nov de 2017 às 17:02, Mike Kluev via swift-evolution
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> escreveu:
> On Mon, 13 Nov 2017 22:30:25 +0100 David Hart <da...@hartbit.com
> <mailto:da...@hartbit.com>> wrote:
> > On 13 Nov 2017, at 05:52, Slava Pestov <spes...@apple.com
> > <mailto:spes...@apple.com>> wrote:
> >
> >> On Nov 12, 2017, at 8:11 PM, Brent Royal-Gordon via swift-evolution
> >> <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
