What does this return?
int x = 1;
defer x = 2;
return x;The Defer Technical Specification: It Is Time
51–60 of 77 posts
Re: The Defer Technical Specification: It Is Time
#52What does this return? int x = 1; defer x = 2; return x;
That 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);Re: The Defer Technical Specification: It Is Time
#53What does this return? int x = 1; defer x = 2; return x;
That 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);
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.
Re: The Defer Technical Specification: It Is Time
#54Earlier quoted context omitted.
That's what it does in Go too. This is totally defer in the Go sense (except they fixed the scoping issue).
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 { free(foo); }
}
char c = *foo;
Re: The Defer Technical Specification: It Is Time
#55Earlier quoted context omitted.
That's what it does in Go too. This is totally defer in the Go sense (except they fixed the scoping issue).
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…
> What happens in this C proposal if you put a defer request inside a loop? Is it a compile time error, do they somehow to try to give it meaningful semantics, or is it undefined behavior?
The action runs at the end of the loop-body, before the next iteration. It does this because the loop-body is the enclosing block, and a defer will always run when its enclosing block ends. As described in the article, this is intentionally-so and makes it possible to acquire a mutex inside a loop while automatically releasing it before the next iteration, something which is easy to get wrong in Go.
Re: The Defer Technical Specification: It Is Time
#56> 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 potent…
Block-based defer is also important when using macros that inserts blocks. They can use defer without care for how nested they are invoked.
Re: The Defer Technical Specification: It Is Time
#57> 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.
Agreed, the example immediately made me see it as an example for the Obfuscated C contest.
Re: The Defer Technical Specification: It Is Time
#58Earlier quoted context omitted.
I 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..."
In a way that makes sense though, once you're at a level where you can not only write Ruby, but write books about Ruby, surely very few things would astonish you.
That's why I always watch the newbies squirm trying to read my/our documentation.
No feedback is ever as honest as unvarnished confusion.
Re: The Defer Technical Specification: It Is Time
#59Regarding 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
var a = 0
fn var a = 0
for fn i := …
Edit: Same for iifes. Everyone uses them, so turn these into proper embedded blocks!
Re: The Defer Technical Specification: It Is Time
#60I 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