Why is this feature entangled with lambdas? Why is defer not a block which is sugar for a goto? Probably the answer is "we want capturing" but this only exists in Go because of its defer scoping weirdness. It also doesn't make the feature foolproof, as in what if I call fclose() outside the defer lambda? Also lambdas and capturing aren't free? What allocates space for them? What is going on with this feature?
Because there are multiple defer proposals and this one is made to be compatible with the lambda proposals. N2589 for example proposes a simpler defer statement that just defers an expression, so e.g. "defer fclose(f);"
Goto may cross variable initialization, so the code in goto may use a variable that does not exist, theoretically.
Also a goto cleanup becomes complex if you have, say a dozen variables to cleanup.
Anyway, i think this is really syntaxtic sugar for the Cpp destructor. I peresume that the lambda will create an object, which will hook itself to the same mechanism that calls cpp destructors at the end of blocks.
And, as all major c compilers are also cpp compilers this seems a good idea to me. And ofcourse the lamda syntax seems same as cpp. So rhats where all this comes from.
