Slightly OT: I don't like defer much, it's just another way to do automated RAII style cleanups. It has slightly different tradeoffs than RAII (it's more of an

Slightly OT: I don't like defer much, it's just another way to do automated RAII style cleanups. It has slightly different tradeoffs than RAII (it's more of an "in-line" way of coding things) but in the end it's another high-level feature that obfuscates the actual control flow. To be clear, I don't think that chains of cleanup-labels with corresponding gotos are better. As a long-time OOP basher, I find myself using more and more explicit state structures with "object" semantics: There's a destructor that cleans the state up from every possible configuration except "uninitialized". As far as possible, objects should already be considered initialized when cleared to 0. (This idiom is called ZII, or zero-is-initialization). A problem with defer is that if one has to split what the function does in multiple functions, defer breaks, and one needs a completely different solution (explicit state structure). Not to praise it too much but with RAII you don't pay that cost. In other words, as so many language features, defer offers to save early typing work early, at the expense of later friction, or even of requiring a re-write, when the times comes to solidify the code structure. Disclaimer: I've never actually typed the word defer in any programming language. :-)