> On 15 Nov 2017, at 03:56, Howard Lovatt via swift-evolution > <[email protected]> wrote: > > Having read all the arguments for what to add to local functions it still > strikes me as a poor use of engineering resources to fix them (though I do > agree they have problems). A better use of resources would be: > > 1. Deprecate local functions.
Even if I agreed, which I don’t, I’m fairly sure it’s much too late in Swift’s timeline to deprecate something as huge as local functions. > 2. Allow closures when assigned to a function type to be: > 2a. Recursive. > 2b. Annotatable with: > 2bi. @inline > 2bii. @escaping > 2c. Generic. > > That would be a similar engineering effort and give a better short term > result of better closures which would be much more widely applicable as well > as addressing the issues with local functions. > > It also gives a better long term result of not having to maintain local > functions. > > > -- Howard. > > On 15 November 2017 at 09:08, Alex Lynch via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > The inference algebra just suggested was enjoyable to read, but is still a > new syntax. Which is interesting and deserving of its own proposal. The > purpose of this proposal is simply to introduce the existing capture syntax > to local functions. Thanks to everyone's feedback pointing out that the > `self` reference analysis is a deeper question than initially realized. > > Alex > > On Tue, Nov 14, 2017 at 4:36 PM, Mike Kluev via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > On 14 November 2017 at 21:02, David Hart <[email protected] > <mailto:[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] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
