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

[Howard Lovatt]

Sorry for the delay in replying - I was called up for jury duty!

For recursive closures the compiler would require two changes; if the
variable is a function type then:

  1. It can reference itself, e.g. `let fact: (Int) -> Int = { $0 < 2 ? 1 :
$0 * fact($0 - 1) }` becomes legal. This is not difficult to do because
`fact` is a pointer and therefore of known size.
  2. When a reference to a function type is made and that function isn't
known, the compiler puts a placeholder in (it knows the size - it is a
pointer) and then comes back and fills in the blank latter (just as it
currently does for functions).

These are not show stoppers, it is what the compiler already does for
functions.

Will respond to generics comments in reply to Robert Widmann email.

  -- Howard.

On 15 November 2017 at 17:01, Slava Pestov <spestov at apple.com> wrote:

>
>
> On Nov 14, 2017, at 6:56 PM, Howard Lovatt via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>   2. Allow closures when assigned to a function type to be:
>       2a. Recursive.
>
>
> Local functions can also be mutually recursive:
>
> func f() {
>   func foo() { bar() }
>   func bar() { foo() }
> }
>
> This would not work with let bindings, which are not visible before the
> location where they are defined.
>
>       2b. Annotatable with:
>             2bi.  @inline
>
>
> Neither closures nor local functions benefit from being annotated with
> @_inlineable, because they can only be referenced from inside their
> defining function, and not across module boundaries. So the optimizer can
> already inline the function or closure if needed.
>
>             2bii. @escaping
>       2c. Generic.
>
>
> See my other response to this thread.
>
> Slava
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171117/cb9dcb2d/attachment.html>