28

What is the practical use of nested functions? It only makes the code harder to read and doesn't make a particular case easy.

func chooseStepFunction(backwards: Bool) -> (Int) -> Int {
    func stepForward(input: Int) -> Int { return input + 1 }
    func stepBackward(input: Int) -> Int { return input - 1 }
    return backwards ? stepBackward : stepForward
}

Source

mfaani
  • 33,269
  • 19
  • 164
  • 293
Esqarrouth
  • 38,543
  • 21
  • 161
  • 168

4 Answers4

53

I think the core of your question is: Why not use private function instead of an ugly nested function?

Simply put, nested functions can ease readability and encapsulation.

Similarly one can ask, what's the practical use of local variables (of a function) vs instance variables? To me it's really the same question. Only that nested functions are less common.

Readability

A private function can still be accessed from other functions in your class. The same isn't true for nested functions. You're telling your developers, this only belongs to this function (contrary to private functions where they belong to the entire class). Back off and don't mess with it, if you need similar capability, go write your own!

The moment you see a private function you have to think, which function will call it. Is it the first function or the last? Let me search for it. Yet with a nested function you don't have to look up and down. It's already known which function will call it.

Also if you have 5 private functions, where 3 of them are called in a single public function then by nesting them all under the same public function you're communicating to other developers that these private functions are related.

In short, just as you don't want to pollute your public namespace, you don't want to pollute your private namespace.

Encapsulation

Another convenience is that it can access all the local parameters to its parent function. You no longer need to pass them around. This would eventually mean one less function to test, because you've wrapped one function inside another. Additionally if you're calling that function in a block of the non-nested function, then you don't have to wrap it into self or think about creating leaks. It's because the lifecycle of the nested function is tied to the lifecycle of its containing function.

Another use case would be when you have very similar functions in your class, say like you have:

extractAllHebrewNames() // right to left language
extractAllAmericanNames() // left to right language
extractAllJapaneseNames() // top to bottom language

Now if you have a private func named printName (that prints names), it would work if you switch the case based on language, but what if just you don't/can't do that. Instead you can write your own nested functions (They could all now have the exact same name. because each is in a different namespace.) inside each separate extract function and print the names.

Your question is somewhat similar, to why not use 'if else' instead of a 'Switch case.

I think it's just a convenience provided (for something that can be dealt without using nested functions).

NOTE: A nested function should be written before it's callsite within the function.

Error: use of local variable 'nested' before its declaration

func doSomething(){
    nested()
    
    func nested(){
        
    }
}

No Error:

func doSomething(){
    func nested(){
        
    }
    
    nested()
}

Similarly a local variable used in a nested function must be declared before the nested function


BE AWARE:

If you're using nested functions, then the compiler won't enforce self checks.

The compiler is not smart enough. It will NOT throw error of:

Call to method 'doZ' in closure requires explicit 'self.' to make capture semantics explicit 

This could result in hard to find memory leaks. e.g.

class P {
    var name: String
    
    init(name: String) {
        print("p was allocated")
        self.name = name
    }
    
    func weaklyNested() {
        weak var _self = self
        func doX() {
            print("nested:", _self?.name as Any)
        }
        
        DispatchQueue.main.asyncAfter(deadline: .now() + 1) {
            doX()
        }
    }
    
    func stronglyNested() {
        func doZ() {
            print("nested:", name)
        }
        
        DispatchQueue.main.asyncAfter(deadline: .now() + 2) {
            doZ() // will NOT throw error of: `Call to method 'doZ' in closure requires explicit 'self.' to make capture semantics explicit`
        }
    }
    
    deinit {
        print("class P was deinitialized")
    }
}

class H {
    var p: P
    
    init(p: P) {
        self.p = p
    }
}

var h1: H? = H(p: P(name: "john"))
h1?.p.weaklyNested()
h1 = nil // will deallocate immediately, then print nil after 2 seconds

var h2: H? = H(p: P(name: "john"))
h2?.p.stronglyNested()
h2 = nil // will NOT deallocate immediately, will print "john" after 2 seconds, then deallocates

tl;dr solution:

  • use weak var _self = self and inside the nested function reference to self with the weak reference.
  • don't use nested functions at all :( Or don't use instance variables inside your nested functions.

This part was written thanks to this original post from Is self captured within a nested function?

mfaani
  • 33,269
  • 19
  • 164
  • 293
  • This is a great explanation and reading Fowler's book Refactoring, nesting functions is something he does as well. I'm not completely sold however as the functions tend to get pretty big and a bit messy compared to breaking out to private functions... – Joakim Sjöstedt Aug 04 '22 at 09:35
2

One use case is operations on recursive data structures.

Consider, for instance, this code for searching in binary search trees:

func get(_ key: Key) -> Value? {
    func recursiveGet(cur: Node) -> Value? {
        if cur.key == key {
            return cur.val
        } else if key < cur.key {
            return cur.left != nil ? recursiveGet(cur: cur.left!) : nil
        } else {
            return cur.right != nil ? recursiveGet(cur: cur.right!) : nil
        }
    }

    if let root = self.root {
        return recursiveGet(cur: root)
    } else {
        return nil
    }
}

Of course, you can transform the recursion into a loop, doing away with the nested function. I find recursive code often clearer than iterative variants, though. (Trade off vs. runtime cost!)

You could also define recursiveGet as (private) member outside of get but that would be bad design (unless recursiveGet is used in multiple methods).

Raphael
  • 9,779
  • 5
  • 63
  • 94
1

There is the principle (since Objective-C) that "code can be data". You can pass code around, store it in a variable, combine it with other code. This is an extremely powerful tool. Frankly, if I didn't have the ability to treat code as data, most of the code I write would be ten times harder to write, and ten times harder to read.

Functions in Swift are just closures, so nested functions make perfectly sense, since this is how you write a closure when you don't want to use one of the many available shortcuts.

gnasher729
  • 51,477
  • 5
  • 75
  • 98
-1

In your example, you can create a variable which is also a function like this:

var myStepFunction = chooseStepFunction(true)

myStepFunction(4)

The benefit of nested function is really nice. For example, let's say you are building an app for the calculator, you can have all your logic in one function, as the following:

func doOperation(operation: String) -> ((Double, Double) -> Double)? {
    func plus(s: Double, d: Double) -> Double {
        return s + d
    }
    func min(s: Double, d: Double) -> Double{
        return s - d
    }
    switch operation {
        case "+":
            return plus
    case "-" :
        return min
    default :
        return nil
    }
}

var myOperationFunction = doOperation("-")?(4, 4) // 0
var myOperationFunction2 = doOperation("+")?(4, 5) //9

In some cases, you are not allowed to see the implementation of some function, or not responsible for them. Then hidding them inside other function is really a good approach. For instance, assume that you colleague is reaponsible for developing the plus and min functions, he/she will do that, and you just use the outer function.

It is deferent from closure, because in clouser, you pass your logic to other logic, which will call yours. It is kind of plugin. For instance, after calling the http request, you can pass the code that you want your app to do when receiving the response from the server

William Kinaan
  • 28,059
  • 20
  • 85
  • 118
  • 3
    Why not just use private functions? Your example with func("+")?(4,5) is really ugly and hardly readable. These are not good practical uses because I think this task will be completed better in other ways – Esqarrouth Oct 18 '15 at 12:04
  • @Esqarrouth Better yet, just use a closure, or eeeeven better, use the `(+)` or `(-)` as closures, directly – Alexander Jul 27 '17 at 04:21