It's mostly that, but it happens the other way around to some extent too.
Compilers sometimes decide they should be able to do something and the standard is overly permissive. Then, eventually, maybe the standard gets aligned to what compilers actually felt like doing.
Conversation
do you have a list of examples? I think this is rarer! or I hope so
3
Isn’t this just a normal compiler extension though?
1
It is. it’s enabled by default in gcc, which I think makes it relevant. It has terrifying codegen, and clang thankfully refuses to support it.
In 2021, gcc will make the stack executable and execute code there if you use it. There’s a warning — not on by default. (-Wtrampolines)
1
2
I seem to recall that those were implemented by RMS in one of his weird "let's import Lisp conventions regardless of whether they make sense" moments, right?
2
2
They were implemented by rms, they are a glorious language extension, now embraced by both swift and c#
1
The feature is nice! The implementation in gcc is dangerous.
2
2
It's a closure unable to live past the block where it's declared and depending on hacks to make it backwards compatible with function pointers.
The concept might have been nice, but they just went with a quick hack instead of designing a serious feature. It was always a hack.
1
3
Smalltalk, Objective-C, Eiffel, etc. predate GCC nested functions.
en.wikipedia.org/wiki/Eiffel_(p
Could have added some syntax for a special function pointer type with a data pointer for captures and it would still be useful today. Probably widely used, and perhaps standardized.
2
1
Eiffel inline agents aren't that far from being like C++11 lambdas used with std::function. You need to pass the captures as arguments but you can bind arguments so the captures are just explicit. It's really quite a lot like a C++11 lambda erased to std::function right away.