What is the benefit of nesting functions (in general/in Swift)

Question

I'm just learning some Swift and I've come across the section that talks about nesting functions:

Functions can be nested. Nested functions have access to variables that were declared in the outer function. You can use nested functions to organize the code in a function that is long or complex.

From here

So if the purported benefit is to "organize the code", why not just have the nested function independently, outside of the outer function? That, to me, seems more organized.

The only benefit I can discern is that you "have access to variables that were declared in the outer function", but this seems trivial in comparison to the messiness of having nested functions.

Any thoughts?

Answer 1

So if the purported benefit is to "organize the code", why not just have the nested function independently, outside of the outer function? That, to me, seems more organized.

Oh, I totally disagree. If the only place where the second function is needed is inside the first function, keeping it inside the first function is much more organized.

Real-life examples here: http://www.apeth.com/swiftBook/ch02.html#_function_in_function

Plus, a function in a function has the local environment in scope. Code inside the nested function can "see" local variables declared before the nested function declaration. This can be much more convenient and natural than passing a bunch of parameters.

However, the key thing that a local function lets you do that you could not readily do in any other way is that you can form the function in real time (because a function is a closure) and return it from the outer function.

http://www.apeth.com/swiftBook/ch02.html#_function_returning_function

Answer 2

One really nice thing is that Xcode will indent nested functions within their parent function in the function pop-up. The function popup is much easier to navigate with functions related to recalculating the layout indented and all grouped in one place.

Answer 3

IMO, the only difference of closures and nested functions is recursion. You can refer the function itself in the function body without a trick.

func a() {
    func b() {
        b() // Infinite loop!
    }
    b()
}

Captured reference type object dies when the capturer dies. In this case, capturer is the function's lexical scope. Which means the function is going to die when it finishes its execution.

Technically, this makes a reference-cycle, and usually discouraged. But this can be useful if you use this wisely.

For example, combine this with asynchronous operations.

func spawnAsyncOp1(_ completion: @escaping () -> Void) {
    enum Continuation {
        case start
        case waitForSomethingElse1
        case retry
        case end
    }
    let someResource = SomeResource()
    func step(_ c: Continuation) {
        switch c {
        case .start:
            return step(.waitForSomethingElse1)

        case .waitForSomethingElse1:
            DispatchQueue.main.asyncAfter(deadline: .now() + .milliseconds(10), execute: {
                let fc = (someResource.makeRandomResult() % 100 < 50) ? .end : .retry as Continuation
                print("\(fc)")
                return step(fc)
            })

        case .retry:
            return step(.start)

        case .end:
            return completion()
        }
    }
    return step(.start)
}

It can make resource management in a coroutine execution simpler without an explicit object instance. Resources are simply captured in function spawnAsyncOp1 and will be released when the function dies.