A quick thing I noticed on a first read (sort of tangential to the rest of the discussion) is that it would be a good idea to land warnings for potential reference cycles sooner rather than later.
I have an (un-rebased) branch that lays out what parts of Sema needs to be touched to make this happen and have SR-1807 (https://bugs.swift.org/browse/SR-1807) open for this in general if anybody would like to pick this up and carry it over the goal line. Note that it’s not quite a starter bug. Otherwise I’ll allocate time to it later on this winter. ~Robert Widmann 2017/11/15 2:01、David Hart via swift-evolution <[email protected]>のメール: > > >> 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]> 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]> wrote: >>>>> 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 >>>> >>> >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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
