Hacker News Reader

Comment by Ao7bei3s | Hacker News Reader

As one would expect. The deferred code runs after the normal code in the function has ended, and before the calling code has resumed. Named return values are in scope and can be read and modified.

Try it and see: https://play.golang.org/p/1ozFWDj15a

View on HN

Cool. Can anything execute between the end of the deferer and the start of the deferred?

Anything as from any other thread/goroutine? Yes of course, all shared data must be protected from races.

If you mean in the same context then, no.

I'm thinking of it in the way that the interpreter works in JavaScript with tasks. If you setTimeout(A, 0), inside B, then after B returns, A is called, but any other tasks previously inserted into the queue are called first.

So I think that means I was asking about execution in the same context (as in memory context), unless you mean stack frame by context, in which case, I think i understand that because the caller returns the value of the deferred, they are in the same stack frame, and nothing else could insert in that frame between them. I'm not sure you know what i mean, but do i have it about right?

I don't really understand this, but i think I'm getting somewhere.

It's much simpler than that. It's just a way of defining cleanup functions without having a language-level concept of destructors. Here's an example: https://gobyexample.com/defer.

This simple example should explain everything:

    package main

    import "fmt"

    func function1() {
        defer fmt.Println("function1: defer a")
        fmt.Println("function1: inside")
        defer fmt.Println("function1: defer b")
    }

    func main() {
        fmt.Println("main: before function1")
        function1()
        fmt.Println("main: after function1")
    }

Here is the output:

    main: before function1
    function1: inside
    function1: defer b
    function1: defer a
    main: after function1

All defers run in LIFO order at the point when a function returns before the function returns execution back to the caller.

Got it thanks a lot, that's very clear.

Reply on news.ycombinator.com