6 ms·
The Defer Technical Specification: It Is Time
- Mond_ 1y agoSeems like a perfect fit for C, and glad to see we're trying to avoid stepping into that funny pitfall Go has with its function-scoped defer keyword. Glad to see C is evolving and standardizing.
- codr7 1y agoI've been doing properly scoped defers in C since forever, as long as you have access to cleanup attributes and nested functions it's no big deal. https://github.com/codr7/hacktical-c/tree/main/macro https://github.com/codr7/hacktical-c/tree/main/macro
- wahern 1y agoYes, the proposal is tailored so that other than simple syntax support no new semantics need to be implemented within GCC to support defer, though clang will need to finally add support for nested functions--in spirit if not the literal GCC extension.[1] The proposal also gives consideration to MSVC's try/finally to minimize the amount of effort required there to support defer. [1] Because defer takes a block, not a simple statement. And deferred blocks can be defined recursively--i.e. defer within a defer block.
- fuhsnn 1y ago>the proposal is tailored so that other than simple syntax support no new semantics need to be implemented within GCC Not just GCC, but you're right it's tailored, to the same "unwinding" queue that C++ destructor, stack-VLA de-allocation and __attribute__((cleanup)) shared, won't fit into the current state of language otherwise. Clang share more frontend between C and C++ so I imagine they can implement it as hidden C++ lambda scope-guards, the nested scenario is just full-capturing lambdas inside another.
- saagarjha 1y agoPlease don’t use nested functions; they’re a security nightmare.
- Animats 1y agoUgh. Go's "defer" is reasonably clean because Go is garbage-collected. So you don't have to worry about something being deleted before a queued "defer" runs. That's well-behaved. This is going to be full of ugly, non-obvious problems. Interestingly, it's not really "defer" in the Go sense. It's "finally", in the try/finally sense of C++, using Go-type "defer" syntax". This mostly matters for scope and ownership issues. If you want to close a file in a defer, and the file is a local variable, you have to be sure that the close precedes the end of block de-allocation. Most of the discussion in the article revolves around how to make such problems behave halfway decently. "defer" happens invisibly, in the background. That's contrary to the basic simplicity of C, where almost nothing happens invisibly.
- codr7 1y agoThe point of defer is to put the cleanup logic in one place for local variables though, so the risk of someone else deleting it isn't a thing.
- deleted 1y ago[deleted]
- jayd16 1y ago> It's "finally", in the try/finally sense of C++ What sense is that? C++ doesn't have finally and the article explicitly calls out how its not like destructors.
- Jtsummers 1y ago> The central idea behind defer is that, unlike its Go counterpart, defer in C is lexically bound, or “translation-time” only, or “statically scoped”. What that means is that defer runs unconditionally at the end of the block or the scope it is bound to based on its lexical position in the order of the program. The only reasonable way for defer to behave. Function scoped never made sense to me given the wasted potential. The demonstration with loop and mutex being a good one.
- chrsig 1y agoyeah, I've always just extracted the loop body into a new function as a result
- infogulch 1y agoI've created a lambda and called it inline to force lexically scoped defer semantics. Works fine and reads fine imo.
- chrsig 1y agoI've definitely done that as well. I generally don't have a problem with it, but it makes for an extra conversation the first time someone sees the pattern. Given how some of the other ergonomic changes in go have gone (closures capturing loop variables, for instance), I'd support a change to lexical scoped defers if it were on the table.
- gblargg 1y agoBlock-based defer is also important when using macros that inserts blocks. They can use defer without care for how nested they are invoked.
- topspin 1y agoRegarding 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.
- dgunay 1y agoIt's incredibly ugly but you could sort of hack in a smaller-scoped defer using anonymous functions: https://go.dev/play/p/VgnprcObPHz https://go.dev/play/p/VgnprcObPHz
- topspin 1y agoYeah, I get it. There's an idiom. Still, that glitch is guaranteed to catch everyone off guard, experienced or otherwise, when taking up golang. As I said, it's an entry on the list, and such a list exists for most (all?) mainstream languages. At least it's minor compared to nil, a flaw somehow promulgated in a brand new language many years after anyone purporting to be a language designer would or should have known to avoid. That's a mystery for the ages right there.
- hinkley 1y agoI love the Principle of Least Astonishment, but I first encountered it in the Ruby book and I gave up reading it halfway through because I kept thinking, "He and I have very different definitions of astonishing..."
- throw-qqqqq 1y agoAnother cool difference between this and Go’s ‘defer’, is that it doesn’t allocate memory on the heap. Go’s ‘defer’ does and it has a small performance cost compared to just calling the .release() or whatever yourself… shrugs At least this was the case last I did benchmarks of my Go code. Dno if they changed that.
- klodolph 1y agoDoes go’s defer allocate on the heap? I thought it would only do that if necessary.
- pkaye 1y agoI know they implemented an optimization back in go 1.13. Not sure if that will help. https://github.com/golang/proposal/blob/master/design/34481-opencoded-defers.md https://github.com/golang/proposal/blob/master/design/34481-...
- zyedidia 1y agoWhat is the recommended way to use defer to free values only on an error path (rather than all paths)? Currently I use goto for this: void* p1 = malloc(...); if (!p1) goto err1; void* p2 = malloc(...); if (!p2) goto err2; void* p3 = malloc(...); if (!p3) goto err3; return {p1, p2, p3}; err3: free(p2); err2: free(p1); err1: return NULL; With defer I think I would have to use a "success" boolean like this: bool success = false; void* p1 = malloc(...); if (!p1) return NULL; defer { if (!success) free(p1) } void* p2 = malloc(...); if (!p2) return NULL; defer { if (!success) free(p2) } void* p3 = malloc(...); if (!p3) return NULL; defer { if (!success) free(p3) } success = true; return {p1, p2, p3}; I'm not sure if this has really improved things. I do see the use-case for locks and functions that allocate/free together though.
- lelanthran 1y agoI don't even bother with `error1`, `error2`, ... `errorN`. I initialise all pointers to NULL at the top of the function and use `goto cleanup`, which cleans up everything that is not being returned ... because `free(some_ptr)` where `some_ptr` is NULL is perfectly legal.
- ayende 1y agoThat is a well structure system, yes Both cleanup for error and allocation happens in the same place That means you won't forget to call it, and the success flag is an obvious way to ha dle it
- deleted 1y ago[deleted]
- loeg 1y agoCan also use a different variable name for the success case and null out any successfully consumed temporaries. void* p1 = malloc(); if (!p1) return failure; defer { free(p1); } ... someOther->pointer = p1; p1 = NULL; return success;
- bobmcnamara 1y agoI'm not sure I'd do either for this trivial case, but it might make sense where the cleanup logic is more complex? void* p1 = malloc(...); void* p2 = malloc(...); void* p3 = malloc(...); if(p1 && p2 && p3) return {p1, p2, p3}; free(p3); free(p2); free(p1); return NULL;
- kats 1y ago[flagged]
- deleted 1y ago[deleted]
- kats 1y ago[flagged]
- _kst_ 1y agoThe author is the project editor for the ISO C standard. (And I hardly think that analyzing speculating about the motivation for the author's chosen nickname is constructive.)
- kats 1y agoGreat! I'm a programmer. And I've sure spent too much time on C++isms. > (And I hardly think that analyzing speculating about the motivation for the author's chosen nickname is constructive.) Nope! Gets right to it. This is really building C++ (but this time how I want). It adds work for every C programmer who has to check off a whole bunch of small tasks to keep a codebase living for many years.
- spacechild1 1y ago"ThePhD" stands for "The Phantom Derpstorm", though.
- saagarjha 1y agoGuys is it C++ when I don’t accidentally leak memory
- lukaslalinsky 1y agoEver since I started working with Zig, I came to realization that its errdefer is even more useful than defer itself. But you can't implement errdefer in C, since there is no standard/disambiguous way of returning errors.
- infogulch 1y agoCan you expand on how errdefer works in zig? I'm not familiar.
- Jtsummers 1y agohttps://ziglang.org/documentation/master/#errdefer https://ziglang.org/documentation/master/#errdefer defer always executes on scope exit, errdefer executes on an error exit. In principle, this is similar to the logic of a try/catch/finally: try { // whatever } catch { // errdefer would belong here } finally { // defer would happen here }
- loeg 1y agoZig has a special / compiler-known ADT for "value OR error". This is similar to Result<T,E> in Rust. Or in C++, e.g., folly::Expected<T,E>. The Zig one is so special and compiler-blessed that there is special syntax for defer blocks that only run when the function return is an error variant of that result ADT -- errdefer.
- fwlr 1y agoThe author takes great care to rebut a common theme among objections to the proposal - “this isn’t necessary if you just write code better”. I am reminded of this fantastic essay: > If we flew planes like we write code, we’d have daily crashes, of course, but beyond that, the response to every plane crash would be: “only a bad pilot blames their plane!” > This doesn’t happen in aviation, because in aviation we have decided, correctly, that human error is an intrinsic and inseparable part of human activity. And so we have built concentric layers of mechanical checks and balances around pilots, to take on part of the load of flying. Because humans are tired, they are burned out, they have limited focus, limited working memory, they are traumatized by writing executable YAML, etc. > Mechanical processes are independent of the skill of the programmer. Mechanical processes scale, unlike berating people to simply write fewer bugs. (https://borretti.me/article/introducing-austral#goals https://borretti.me/article/introducing-austral#goals)
- smadge 1y agoI agree with that, but: - the language still allows you write the unsafe version even with defer. By your logic fallible humans will continue to write these class of bugs because they can. - adding a whole new flow control construct will introduce a whole new class of bugs. The dog barking example is cool for demonstrating how defer works, but is completely unreadable for what it does, programmers will write code like that because they are allowed to, and unreadable code becomes buggy code. - to make a language safer you should remove the things that make unsafe behavior possible, not add constructs which make safe behavior easier.
- globnomulous 1y ago> is completely unreadable for what it does Maybe I'm putting too much emphasis on "completely unreadable" rather than the rest of the quotation, but I find the example crystal clear, and I'd never expect code intended to illustrate, clearly and loudly, language features to read naturally. > to make a language safer you should remove the things that make unsafe behavior possible, not add constructs which make safe behavior easier. Some of this guy's other (equally superb) blog posts explain why this isn't an option: it breaks decades' worth of C code, and the C standards group is strongly committed to ensuring that C that compiled 20, 30, 40 years ago continues to compile. Regardless, I find it incredibly weird to read the statement "you should [...] not add constructs which make safe behavior easier," no matter the contents of "[...]." If your goal is to improve the security of a programming language or the maintainability of code in that language, and you don't want breaking changes, this isn't just your best option. It's your only option, I think.
- ChrisMarshallNY 1y agoPretty much the only time I use it, is if the act of doing some cleanup might cause a change (like a mutable function in a communication API, or letting go of a reference may interfere with a last operation). Generally, I find it isn’t necessary. I can usually figure out a way to make it work with standard flow control. In my case, it’s the Swift language.
- Wumpnot 1y agoCan't really blame MS for saying ..just use C++.. they aren't exactly wrong.
- neilv 1y ago> Here’s a basic example showing off some of its core properties Why not make the string literals in the code identify their positions in the output, to expose the behavior, rather than obfuscate it? Then the reader only has to work through the code, to see why it would have that order. It currently looks like a puzzle intended to be harder for the reader to understand than it needs to be.
- hyperhello 1y agoI was thinking it might be clearer with defer printf("2"); printf("1"); for example.
- gblargg 1y agoAgreed, the example immediately made me see it as an example for the Obfuscated C contest.
- fuhsnn 1y agoYou can play with defer in Linux/VM with slimcc[1] today! It only diverges from the TS in keyword being _Defer, as well as several goto constraint violations not detected, bright side is you can witness why they are constraint violations... [1] https://github.com/fuhsnn/slimcc https://github.com/fuhsnn/slimcc
- hyperhello 1y agoWhat does this return? int x = 1; defer x = 2; return x;
- gizmo686 1y agoThat will return 1. The defered code is executed after the return value is computed. This lets you do things like: char *str = foo(); defer { free(str); } return strlen(str);
- Jtsummers 1y agohttps://thephd.dev/_vendor/future_cxx/technical%20specification/C%20-%20defer/C%20-%20defer%20Technical%20Specification.pdf https://thephd.dev/_vendor/future_cxx/technical%20specificat... Right, there's a demonstration of GP's question (or a variation) on page 10 of the draft technical specification.
- sbrudenell 1y agoI always thought golang's defer was a readability nightmare because it obfuscates execution order. OP's "basic example" is ... a great example of obfuscation. try/finally doesn't have this problem. It can add indents, but I'd so much rather read a function with 4 indents than 4 defers
- aeijdenberg 1y agoThe TS doesn't seem to provide for a way to modify return values for the function. For example the following is a common pattern in Go using defer to ensure that errors closing a writeable file are returned: 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 }
- deleted 1y ago[deleted]