The Defer Technical Specification: It Is Time

Post by IshKebab » Thu, Mar 20, 2025, 6:35 AM UTC

gizmo686 wrote: post #54

Animats wrote: post #47

Earlier quoted context omitted.

Not quite. "The central idea behind defer is that, unlike its Go counterpart, defer in C is lexically bound, or “translation-time” only, or “statically scoped”" Defer in Go puts the deferred action on a run time to-do list that's processed at function exit. You can queue up deferred actions from a loop in Go. Not in this proposal for C. What happens in this C proposal if you put a defer request inside a loop? Is it a…

Loops in C introduce a new lexical scope, so the defer runs once for every loop iteration. Assuming you are using defer for destructor purposes, and use it where you declare your variable, this would generally be what you want, as it frees the memory at the same time it goes out of scope. The flip side of this is that code like the following would be broken: char *foo = NULL; if (true) { foo = calloc(1,1); defer { fr…

Post by lmm » Thu, Mar 20, 2025, 7:31 AM UTC

rollulus wrote: post #63

topspin wrote: post #7

Regarding the statements on golang's defer: "the defer call is hoisted to the outside of the for loop in func work" Astonishing. Add that to the list of golang head scratchers. That is one of the biggest "principle of least astonishment" violations I've ever seen. Disclaimer: Not a golang hater. Great language. Used it myself on occasion, although I remain a golang neophyte. Put away the sharp objects.

Say that the defer would execute inside for loops, what would make you more astonished: loops and functions are the exceptions, or defers execute at the end of any block? I would prefer the latter of these two. But then the consequence is that a defer in an if-block executes instantly, so you cannot conditionally defer anymore. So it seems that the rules for when deferees execute need to be arbitrary, and "only funct…

Post by zombot » Thu, Mar 20, 2025, 7:46 AM UTC

wruza wrote: post #59

topspin wrote: post #7

Regarding the statements on golang's defer: "the defer call is hoisted to the outside of the for loop in func work" Astonishing. Add that to the list of golang head scratchers. That is one of the biggest "principle of least astonishment" violations I've ever seen. Disclaimer: Not a golang hater. Great language. Used it myself on occasion, although I remain a golang neophyte. Put away the sharp objects.

My biggest astonishment is how people continue to shoot themselves in the foot by not making scope vs function declarations explicit. For the reasons that “someone will misunderstand complicated ideas, so let’s make it implicit” or something. While there could be just: defer x // scope scoped defer fn x // function scoped Also: var a = 0 fn var a = 0 for fn i := … But we have this allergy to full control and invent t…

Post by aeijdenberg » Thu, Mar 20, 2025, 7:58 AM UTC

    func foo() (retErr error) {
        f, err := os.Create("out.txt")
        if err != nil {
            return fmt.Errorf("error opening file: %w", err)
        }
        defer func() {
            err := f.Close()
            if err != nil && retErr == nil {
                retErr = fmt.Errorf("error closing file: %w", err)
            }
        }()
        _, err = f.Write([]byte("hello world!"))
        return err
    }

Post by Someone » Thu, Mar 20, 2025, 10:17 AM UTC

rollulus wrote: post #63

topspin wrote: post #7

Regarding the statements on golang's defer: "the defer call is hoisted to the outside of the for loop in func work" Astonishing. Add that to the list of golang head scratchers. That is one of the biggest "principle of least astonishment" violations I've ever seen. Disclaimer: Not a golang hater. Great language. Used it myself on occasion, although I remain a golang neophyte. Put away the sharp objects.

Say that the defer would execute inside for loops, what would make you more astonished: loops and functions are the exceptions, or defers execute at the end of any block? I would prefer the latter of these two. But then the consequence is that a defer in an if-block executes instantly, so you cannot conditionally defer anymore. So it seems that the rules for when deferees execute need to be arbitrary, and "only funct…