Deferred actions are not explicit at the exit points.

That's quite implicit. You can no longer reason about a local piece of code; you now have to know its lexical nesting up to top level to see if it's inside a guard block that might trigger hidden behavior.

That's still local at the scope level though, which is quite acceptable.

Plus, to handle the free or the leak if you had forgotten to free a resource at the exit point would also require to "know its lexical nesting up to top level".

Between goto and longjump and co, C has much worse non-local behavior than defer.

Goto isn't nonlocal. You know you'll only every jump from them, and that you'll only ever jump to the specified label.

The specified label is what makes goto no-local. You need to check the whole codebase to find out where you'll land.

By your definition only [1] "come from" would be non-local.

[1] https://en.wikipedia.org/wiki/COMEFROM

FWIW, Normally the term "non local goto" is reserved for control transfer beyond the current activation frame. So C goto is strictly local, bit longjmp would be non-local.

> the whole codebase

You can't goto out of a function, and you know there's exactly one such label inside it. If goto isn't local, then neither are function calls, since the function could be defined anywhere in the codebase.

>You can't goto out of a function

You can with a goto expression and a label address available - though the behavior is undefined in C, so bets are off.

And you can with longjump/setjump more explicitly.

Are you talking about this? https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html It's a GNU extension, not part of standard C at all.

it's control flow. What you are saying is like saying "while loops are implicit: you can no longer reason about code; you now must think about the state of the check boolean to see if it will trigger the hidden behaviour of going back to the top of the loop because there's no explicit "go back to the top of the block" statement.

With a while loop, to know what happens at the bottom of the block, you only need to check the top of the block. With defer, to know what happens at the bottom of the block, you need to check the entire contents of the block.

What? Any statement inside a while loop could mutate the loop variable and then all bets are off.

You have to check every line of a while loop to know what’s going on. Heck, another thread could hold a pointer aliasing the loop variable and then mutate it, causing the loop to terminate for no obvious reason.

My point is that you know at the end of the while loop, it's going to test the loop variable you wrote at the beginning, no matter what's in the loop body. The fact that other things could change the variable isn't relevant. With defer, you don't know what will happen at the end of a block without looking through the whole thing.

Why does it matter so much what code runs at the end of a block?

> With a while loop, to know what happens at the bottom of the block, you only need to check the top of the block.

Anyway, what could possibly happen at the end of a while loop, besides going back to the begining for the test?

Besides, if you have a bug in your code, you will have to look at the whole block anyway.

It's as much hidden behaviour as destructors being called magically on an object that goes out of scope. In practice it doesn't hinder understandability as much as you think.

> destructors being called magically on an object that goes out of scope

Which C doesn't have.

> Deferred actions are not explicit at the exit points.

They are no less explicit than the actions performed at the end of iterations of for or while loops. In general, for C, understanding the behavior of code requires understanding “is it in a block, and if so what kind of block”; guard blocks would be not generally different.

I wondered about this. Say I have a block, at the end of which I free a bunch of memory. I also have a bunch of other exit points within the block (mostly for catastrophic errors, say). Would a deferred free only apply to the outer scope? Because if so, I really don't see the point at all.

yes, you always run defer. I don't see it in this proposal, but Most languages/frameworks that implement a defer also implement a "error defer" which only gets triggered on some sort of labeled early exit scenario, and some implement "success defer": (i believe this is scopeguard: https://www.youtube.com/watch?v=WjTrfoiB0MQ)

Every defer statement is ultimately pushing a lambda into some stack that is executed when the defer block is exited. With an exception of setjmp/longjmp, I can't think of an existing C construct with similar run-time complexity.

That's indeed tricky: if there's a for loop inside the guarded block which generates many defers, a stack would have to be created to handle them somehow.

The defer would just run at the end of each iteration.

Is it actually a lambda, or is it just essentially appending statements to the end of the scope?

that depends for instance you can safely call free on NULL so you could just append.

However, for some things you can only free/return resources if you successfully created that resource. At which point you would need to use something like a stack.

I think the broader and more accurate point is that defer adds cognitive load to reasoning about the order of execution. It's true that defer (at least everywhere I've seen it executed) is totally explicit and deterministic, but in the case of multiple defers in the same block it can take some thought to reason through exactly what happens when.