In fact, the standard reflects what is happening in the field. So, use `defer` where this is already possible and ping your compiler vendor for those that do not have it yet. If there is enough demand, `defer` may even happen for the next standard release.
That may be true in your bubble, but I don't think this is true in general. There are still a lot C compilers out there, compared to 3 or 4 that do C++.
Thanks for the pointer! Definitively, on the long run these things should go into compilers directly, yes.
BTW, the break continue stuff now works in the development branch.
I notice that in that implementation there is an addition to the compiler state with indirections, whereas in ellipsis all is done with just three local variables; two per-function for knowing if we have to unwind completely and for the return value, and one per loop construct to know if we have to unwind there. All the rest is static information about nestedness and lexicographic ordering of code that can be deduced very early (here in the preprocessor). The result of all of this is a very organized braid of gotos, that in general are mostly optimized out.
This would be much more restrictive that what is proposed, because usually you would add `defer` statements as you go in a block, when you allocate more resources for example.
Also usually you should be able to have several actions,
defer {
one;
two;
}
And the bounding in the proposed feature is sane, I think, it is the surrounding compound statement (AKA `{ ... }` block).
That's not very practical if you have several operations to perform, you'd have to create a specialized function each time. So no, that extension is not an alternative to designing a new flow control feature. (And it is not new, other languages have it already.)
In fact, the standard reflects what is happening in the field. So, use `defer` where this is already possible and ping your compiler vendor for those that do not have it yet. If there is enough demand, `defer` may even happen for the next standard release.