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

[Howard Lovatt]

You can add generic closures with some name mangling and simple
transformations, nothing very hard.

The compiler can emit the following for example:

// User writes
let increment: <T: Numeric>(T) -> T = { $0 + 1 }
increment(1) // 2
increment(1.1) // 2.1


// Compiler issues
struct _Generic_Increment<T: Numeric> { // Mangle name
    let increment: (T) -> T = { $0 + 1 }
}
_Generic_Increment<Int>().increment(1) // 2
_Generic_Increment<Double>().increment(1.1) // 2.1


It's plausible that the compiler can do better than the above, but the
above would be sufficient and is easy to do.

  -- Howard.

On 15 November 2017 at 14:02, Matthew Johnson <matthew at anandabits.com>
wrote:

>
>
> Sent from my iPhone
>
> On Nov 14, 2017, at 6:56 PM, Howard Lovatt via swift-evolution <
> swift-evolution at 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 at 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 at swift.org> wrote:
>>
>>> On 14 November 2017 at 21:02, David Hart <david at 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 at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171115/2347a466/attachment.html>