> It's not the same, defer does not conditionally interrupt the flow of execution, it will always run at the end of a block.
But destructors also don't conditionally interrupt the flow of execution, and always run at the end of a block.
> If I see a defer
The point is that you're not seeing it. In order to know if there's a defer happening at the end of a function you can't just read the end of the function, you need to read the entire function. That's non-local reasoning, which is what Zig professes to abhor.
And in fact defer is worse than destructors here, because a destructor runs the exact same code every time, whereas defer allows arbitrary code, so you need to review every single usage. And you also need to remember not to forget to use it in the first place (which is the classic footgun with defer), so in addition to vetting everywhere you use it, you also need to vet everywhere you might have forgotten to use it.
> But destructors also don't conditionally interrupt the flow of execution, and always run at the end of a block
Why bring up destructors, I was talking about exceptions. Destructors and exceptions are orthogonal concepts, one can be implemented independently of the other. I'm specifically referring to try-catch blocks like those in java.
Compare this:
try { foo(); }
catch { bar(); }
to this:
defer bar();
foo();
In the first one, bar() may or may not run depending if there's an exception. In the second one, bar is guaranteed to run. Thus, it means defer does not conditionally interrupt the flow of execution.
> The point is that you're not seeing it. In order to know if there's a defer happening at the end of a function you can't just read the end of the function, you need to read the entire function.
What? You don't need to read the entire function, you only to scan or check for defers scoped in a block, or in some cases, just the top of a function or block. Wanting to just read the end of a function is unreliable anyway with the existence of early returns (which defer fixes by the way).
You could have made a more compelling (but not necessarily a valid) case by citing zig's try-catch, which makes me think that you are just arguing in abstract without actually having tried writing code that uses defer, or any zig code for that matter.
I cite destructors specifically because Zig denounces destructors as "hidden control flow" while presenting defer as a non-hidden alternative to destructors, which I find to be an incoherent philosophy.
But you were originally talking about exceptions. As I said, destructors and exceptions are distinct concepts, you can't just suddenly interchange those two terms as that would invalidate my whole disagreement, unless you wanted to shift the goal posts a bit to the side.
But destructors also don't conditionally interrupt the flow of execution, and always run at the end of a block.
> If I see a defer
The point is that you're not seeing it. In order to know if there's a defer happening at the end of a function you can't just read the end of the function, you need to read the entire function. That's non-local reasoning, which is what Zig professes to abhor.
And in fact defer is worse than destructors here, because a destructor runs the exact same code every time, whereas defer allows arbitrary code, so you need to review every single usage. And you also need to remember not to forget to use it in the first place (which is the classic footgun with defer), so in addition to vetting everywhere you use it, you also need to vet everywhere you might have forgotten to use it.