Golang defer behavior

Effective Go
states the following regarding defer:

> The arguments to the deferred function (which include the receiver if the function is a method) are evaluated when the defer executes, not when the call executes. Besides avoiding worries about variables changing values as the function executes, this means that a single deferred call site can defer multiple function executions. Here's a silly example.

> for i := 0; i < 5; i++ {
defer fmt.Printf("%d ", i)
}

> Deferred functions are executed in LIFO order, so this code will cause 4 3 2 1 0 to be printed when the function returns.

This example confuses me. If parameters are evaluated when the defer call is executed, then the defers in the for loop should print 5 5 5 5 5 since the defers will be called when the for loop ends, and at that time i would be 5. Evaluating defers at the end of the for loop will thus result in 5 for all calls.

Am I missing something here?

That seems coherent (see also "Defer, Panic, and Recover")

Deferred function calls are executed in Last In First Out order after the surrounding function returns.

This function prints "3210":

func b() {
    for i := 0; i < 4; i++ {
        defer fmt.Print(i)
    }
}

The last call when the defer is evaluated means i=3, the previous to last means i=2 and so on.

Golang spec:

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

> the defers will be called when func ends

yes, but their arguments are evaluated before, while the loop is running.

You have a trickier defer case in "How golang's “defer” capture closure's parameter?" when used with closure (function literal), as detailed in "Why add “()” after closure body in Golang?".

A little further down, the spec also explicitly says that parameters are evaluated at the time the defer statement runs, not at return/panic time when the deferred function is actually called:

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

And yes, it can definitely be confusing that the parameters are evaluated at one time and the function body runs at another. I've been caught by it.

I think your confusion is about what the phrases "the defer executes" and "the call executes" mean. I believe, "the defer executes" is when the flow of control reaches the line starting with defer, i.e. this happens five times inside the loop. In contrast, "the call executes" is when the fmt.Printf("%d ", i) is executed, i.e. when the surrounding function returns.

If this interpretation is correct, the your statement "since the defers will be called when the for loop ends" is wrong (printf will be called after the loop, but defer is called inside), and everything is consistent with the behaviour explained in the other answers.

Defer provides the opportunity to execute code after function is executed. For example, closing a resource after the function terminates. To accomplish this the defer function does a capture of the function execution (captures the variables and state of the function), then the defer is inserted into a GO queue. When the function terminates, GO will determine if any queue is not empty and executes the defer function.