|
d, a, c, b makes perfect sense to me --- it's naturally compositional! There is a style of grey-beard that never wants to reason in parts. He simple loads the whole program into his big brain and works from there: trees through the eyes, forest (maybe, certainly subjective) in the mind. I too am big-brained, but I wholly reject this approach --- it makes for code that is sorely lacking in motivation --- all "what", no "why". With "goto" I need to reconstruct what the arbitrary control flow means. It might be cleanup, it might be something else entirely! With "defer", we have the essence of RIAA without any bad OOP nonsense. The cleanup obligations themselves are literal in the code. You don't need to know the order d, a, c, b run in 99% of the time. The reverse-order semantics indicate the LIFO semantics, which should be enough and tied to e.g. the deadlock avoidance or inter-resources-that-need-cleanup dependency management. And again, whenever you do want to see what the actual order is, the desugarer should always be a click away, perfectly your questions. |
Well said.
I'm reluctant to trust composability in these languages because of abstractions that were supposed to be composable, but turned out as non-composable. Separation of concerns, single responsibility etc are all good ideas, but code that is less explicit seems to make those things harder to verify. (I feel completely differently about composability in genuinely functional, managed programming languages.) In a way, C's qualms should have been mitigated by C++ already; but in fact, C++ has only replaced a small set of problems with a huge one.
> With "goto" I need to reconstruct what the arbitrary control flow means
I agree with your point in general (reading code means reconstructing the whole from the parts, which is more difficult than writing code, i.e., deconstructing the whole into parts) -- but not in this specific case. A proper cascade of gotos is very recognizable. And a broken cascade is fairly recognizable too.
> You don't need to know the order
My experience with C++ destructors (which I didn't write) suggests otherwise. "Trust, but verify"; and for that, explicit code is better. IMO.
> the desugarer should always be a click away
Source code should be readable without external tools, IMO.