Go封包捕获规则与defer有何区别？

Question

The following Go code demonstrates a distinction in the closure-capture rules between defer and go closures. In a tutorial, I was told that for-loop variables have scope limited to the loop body, but something seems different here.

package main

import "fmt"

func deferred() {
    for i := 0; i < 5; i++ {
        defer fmt.Println(i)
    }
}

func cps() {
    clo := new(func())
    *clo = func() {}
    defer func() { (*clo)() }()
    for i := 0; i < 5; i++ {
        oldClo := *clo
        *clo = func() {
            fmt.Println(i)
            oldClo()
        }
    }
}

func cpsCpy() {
    clo := new(func())
    *clo = func() {}
    defer func() { (*clo)() }()
    for i := 0; i < 5; i++ {
        oldClo := *clo
        cpy := i
        *clo = func() {
            fmt.Println(cpy)
            oldClo()
        }
    }
}

func main() {
    fmt.Println("defer")
    deferred()
    fmt.Println("cps")
    cps()
    fmt.Println("cpsCpy")
    cpsCpy()
}

This produces output:

defer
4
3
2
1
0
cps
5
5
5
5
5
cpsCpy
4
3
2
1
0

If the difference is intentional, then what are the different use-cases that justify it?

Answer 1

The spec for defer is clear on this. The spec in general is crucial reading for anyone who cares about stuff like variable capture rules, and relatively short for what it is. What it says here is:

Each time a "defer" statement executes, the function value and parameters to the call are evaluated as usual and saved anew but the actual function is not invoked.

It's also covered in the blog post on defer, panic, and recover.

It's always hard to justify design decisions to everyone's satisfaction, and the defer one in particular does surprise people now and then, notably when you do defer f1(f2(x)) and forget f2(x) will be evaluated immediately.

One thing that may help remember it, though, is that what comes after defer (or go) is a function call, and just the function invocation itself (not even evaluation of params) is shifted in time. The closure defines a block of code, and accessing the variables happens when the code is executed.

---

Since you were curious about the use for the kind of variable capture you get with closures, one example of where it's useful is if you're using a closure with a method like ForEach:

myBTree.ForEach(func (key, value []byte) {
    //...
})

It's nice if, like in a regular for loop, the code between the braces can modify variables in the outer scope. That requires that the closure be accessing the variables, not just their values as of a specific time.