(That was sarcasm, FYI. Obviously it's 2023 and nobody wants to do manual function calling boilerplate as if you're programming 1960's assembly.)
void err() { printf("oops, we failed"); }
...
if (errno) return err();
This cleaned up a lot of my code. (The optimizer would of course inline the function, and the common tail merging would automatically convert it to the goto version in the optimizer. So this was cost-free.)Why C doesn't officially have nested functions is, well, that's C!
It starts with one goto, then one more, then another.
The first goto is usually clever but then someone else arrives and hacks another one because they don't want to change the code too much.
Maybe some day it will. It should anyway
But GCC and Clang already support it, and while I can't find if MSVC does, it probably does
edit: also, now I see that the goto in if (errno) goto err is really just an (inlined) tail call!
In general, any random C compiler is likely to not support that feature, because the way it interacts with function pointers makes it unnecessarily complicated.
Pascal could do it in the 1970s, and even Tiny Pascal could do it, see the listing for the compiler in BYTE.
https://archive.org/details/byte-magazine-1978-09
As for function pointers, a simple solution is to not allow them unless the function is declared `static`. `static` functions don't have a hidden static link.
The problem is doing it in an ABI-compatible way when you already have an ABI. The gcc implementation of nested functions does that - they are compatible with regular function pointers - but at the cost of requiring executable stack on at least some platforms.
And for C compilers that aren't gcc, the question becomes: why partially implement a non-standard gcc feature?
if err != nil {
return nil, err
}