4 ms·

You have accused me of arguing in bad faith twice in one post. This is insulting, not to mention against the HN rules ("assume good faith"). Clearly we disagre

You have accused me of arguing in bad faith twice in one post. This is insulting, not to mention against the HN rules ("assume good faith"). Clearly we disagree on whether a syntax change is minor. But first let me repeat the point I made that you ignored in between your accusations: it really is just syntax. Of the four examples in the second part of your post, if we assume defer is implemented like attribute cleanup and fix up the compile errors, your first and fourth example compile to the identical assembly code: https://godbolt.org/z/n14z5q https://godbolt.org/z/n14z5q https://godbolt.org/z/Ksq1rj https://godbolt.org/z/Ksq1rj I would argue that the best solution is one you didn't present: move the "business logic" into a separate function, one that takes the necessary resources as arguments. This way you're no longer mixing up resource acquisition error handling with business logic, and the function that acquires the resources can use the nested if statement style (or any other style) with no downsides. No surprises here, it again compiles to the identical assembly code: https://godbolt.org/z/b375E9 https://godbolt.org/z/b375E9 In my opinion the nested if style is better than using defer because it's completely linear with no backward jumps. But even if you disagree you can hardly complain about cleanup code being far from init code because the whole resource handling function is less than 20 lines of code regardless of what cleanup style you chose. It doesn't matter, which is why I argue that it's a minor syntax change not worthy of addition to C.

loup-vaillant 6y ago
> it really is just syntax It's really not. When the impact of "syntax" are non-local like that, it's more than syntax. A compiler would handle this beyond the parsing stage. At the very least, it would seriously massage the AST to remove `defer` from it. > if we assume defer is implemented like attribute cleanup and fix up the compile errors, your first and fourth example compile to the identical assembly code: This is to be expected: they ultimately do the same thing, and optimisers are known to do significant, non-local transformations to the code. > move the "business logic" into a separate function, one that takes the necessary resources as arguments. So now I have a function with (likely) too many arguments, that's used only once, and my eyes have to jump around to get to it (or I have to reach for the F2 key). The pyramid may be more visible, but that's a meagre advantage. > In my opinion the nested if style is better than using defer because it's completely linear with no backward jumps. Not even a criterion in my book. I suspect you're having an overly operational mindset. A mindset I suspect has held the whole field back a couple decades. Don't think of it like a backward jump. It's meant to be viewed as deferred execution, triggered by scope exit. > you can hardly complain about cleanup code being far from init code because the whole resource handling function is less than 20 lines of code That was an example, dummy. In real code, I'd have more than 3 things to initialise, and their initialisation might not be as trivial (or as repetitive) as what I've shown here. That's when I really want to read the code from top to bottom, with concerns packed together. Defer/cleanup lets me do that. The other solutions, less so.

loup-vaillant 6y ago

> it really is just syntax It's really not. When the impact of "syntax" are non-local like that, it's more than syntax. A compiler would handle this beyond the parsing stage. At the very least, it would seriously massage the AST to remove `defer` from it. > if we assume defer is implemented like attribute cleanup and fix up the compile errors, your first and fourth example compile to the identical assembly code: This is to be expected: they ultimately do the same thing, and optimisers are known to do significant, non-local transformations to the code. > move the "business logic" into a separate function, one that takes the necessary resources as arguments. So now I have a function with (likely) too many arguments, that's used only once, and my eyes have to jump around to get to it (or I have to reach for the F2 key). The pyramid may be more visible, but that's a meagre advantage. > In my opinion the nested if style is better than using defer because it's completely linear with no backward jumps. Not even a criterion in my book. I suspect you're having an overly operational mindset. A mindset I suspect has held the whole field back a couple decades. Don't think of it like a backward jump. It's meant to be viewed as deferred execution, triggered by scope exit. > you can hardly complain about cleanup code being far from init code because the whole resource handling function is less than 20 lines of code That was an example, dummy. In real code, I'd have more than 3 things to initialise, and their initialisation might not be as trivial (or as repetitive) as what I've shown here. That's when I really want to read the code from top to bottom, with concerns packed together. Defer/cleanup lets me do that. The other solutions, less so.