[swift-evolution] Making capturing semantics of local

[Howard Lovatt]

> Closures cannot replace all uses of local functions. Local functions can
be recursive, and have a generic parameter list.

My response would be add these featurtes to closures, it will make closures
better.

In terms of recursion you can fiddle it:

struct RecursiveClosure<C> {
    var c: C! = nil
}
func factorial(_ n: Int) -> Int {
    var recursive = RecursiveClosure<(Int) -> Int>()
    recursive.c = { x in
        (x == 0) ? 1 : x * recursive.c(x - 1)
    }
    return recursive.c(n)
}
factorial(5) // 120


  -- Howard.

On 27 October 2017 at 15:53, Slava Pestov <spestov at apple.com> wrote:

>
>
> On Oct 26, 2017, at 9:52 PM, Howard Lovatt <howard.lovatt at gmail.com>
> wrote:
>
> It would be easy to provide a fixit.
>
>
> That is still a source breaking change that requires migration, though.
>
> How often are they actually used? I rarely use them and all my use cases
> could be a closure instead.
>
> Also see Mike Kluev example; local functions are arguably worse than
> closures in all cases (provided that you can appropriately annotate the
> function type).
>
>
> Closures cannot replace all uses of local functions. Local functions can
> be recursive, and have a generic parameter list.
>
> Slava
>
>
>   -- Howard.
>
> On 27 October 2017 at 12:26, Slava Pestov <spestov at apple.com> wrote:
>
>>
>>
>> On Oct 26, 2017, at 4:45 PM, Howard Lovatt via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> Rather than expand local function syntax why not deprecate local
>> functions completely
>>
>>
>> I don’t think at this point such a drastic change to the language is
>> likely to happen.
>>
>> Slava
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171027/19725c76/attachment.html>