Sent from my iPhone
> On Nov 14, 2017, at 6:56 PM, Howard Lovatt via swift-evolution
> <swift-evolution@swift.org> 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.
> 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.
I believe generic closures would require adding higher rank types to Swift.
That would be pretty cool but I suspect the engineering effort is at least an
order of magnitude greater than the changes discussed in this thread.
>
> 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
>> <swift-evolution@swift.org> 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
>>> <swift-evolution@swift.org> wrote:
>>>> On 14 November 2017 at 21:02, David Hart <da...@hartbit.com> 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
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
