3 ms·
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
by camgunz 5y ago
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?
- arka2147483647 5y agoGoto 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.
- deleted 5y ago[deleted]
- camel-cdr 5y agoBecause 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);"
- camgunz 5y agoAhhhhh thank you. I had a minor freak out, thanks for the good info!