Why allow function declarations inside function bodies

Question

Why does the syntax allow function declarations inside function bodies?

It does create a lot of questions here on SO where function declarations are mistaken for variable initializations and the like.

a object();

Not to mention most vexing parse.

Is there any use-case that is not easily achieved by the more common scope hiding means like namespaces and members?

Is it for historical reasons?

Addendum: If for historical reasons, inherited from C to limit scope, what is the problem banning them?

It's probably for historical reasons. Namespaces and classes don't exist in C. — Brian Bi, Jul 23 '15 at 21:00
In http://stackoverflow.com/q/6089452/451600 Oliver Charlesworth states "but for the sake of backward compatibility it can't be removed from the language." I find that hard to buy. — Captain Giraffe, Jul 23 '15 at 21:05
@CaptainGiraffe: If it were removed, it would break a considerable amount of existing code. And for what? What benefit would such pain provide? — wallyk, Jul 23 '15 at 21:06
Is there any other instance of context sensitive special case for the declaration form? — imreal, Jul 23 '15 at 21:07
@wallyk That is part of my beef. c++ and c are nowadays not interchangeable, c++ is not a superset of c. You wouldn't compile a codebase from 1993 with a modern c++ compiler. — Captain Giraffe, Jul 23 '15 at 21:10
@CaptainGiraffe: In fact, I do exactly that at my current client. — wallyk, Jul 23 '15 at 21:14
If it were changed today, it would break valid C++ code from *yesterday*. I'm not clear on when you are suggesting this should be (should have been) removed. — Drew Dormann, Jul 23 '15 at 21:16
Warnings for c++-98, removed in 03 I suppose. @wallyk interesting. — Captain Giraffe, Jul 23 '15 at 21:20
I found this source: https://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html - that refers to nested functions as an extension of the GNU C language. It would primarily depend on any compiler implementation that would need them. — KillaBytes, Jul 23 '15 at 21:29
Also see [Why can't I define a function inside another function?](http://stackoverflow.com/q/29967202/1708801) — Shafik Yaghmour, Jul 24 '15 at 02:00

Mats Petersson · Accepted Answer · 2015-07-23T21:53:13.700

2

Whilst many C++ applications are written solely in C++ code, there are also a lot of code that is some mixture of C and C++ code. This mixture is definitely something of C++'s important part of its usefulness (including the "easy" interfacing to existing API's, anything from OpenGL or cURL to custom hardware drivers that are written in C, can pretty much be used directly with very little effort, where trying to interface your custom hardware C driver into a Basic interpreter is pretty diffcult)

If we start breaking that compatibility by removing things "for no particular value", then C++ is no longer as useful. Aside from giving better error messages in a condition that is confusing, which of course is useful in itself, it's hard to see how it's useful to REMOVE this - and that's of course assuming NONE of the C++ is using this in itself - and I wouldn't be surprised if it DOES happen at times even in modern code (for whatever good or bad reasons).

In general, C++ tries very hard to not break backwards compatibility - and this, in my mind, is a good thing. That's why the keyword static is used for a bunch of different things, rather than adding a new keyword, and auto means something different now than it used to in C, but it's not a "new" keyword that could break existing code that happened to use whatever other word chosen (and that is a small break, but nobody really used it for the past 20 years anyway).

edited Jul 23 '15 at 21:53

answered Jul 23 '15 at 21:25

Mats Petersson

126,704
14
140
227

I think Stroustrup said that all the remaining uses of `auto` before its meaning was changed in C++11 were either bugs or compiler test cases. – Brian Bi Jul 23 '15 at 21:27
@Brian: Yes, that would probably be true. – Mats Petersson Jul 23 '15 at 21:28
_"there are also a lot of code that is some mixture of C and C++ code. This mixture is definitely something of C++'s strong points"_ It absolutely is not... – Lightness Races in Orbit Jul 23 '15 at 21:29
@LightnessRacesinOrbit: So you mean that using a C library such as OpenGL, DirectX, MySQL or similar "without having to construct some sort of language binding" is not a benefit to C++? What would you prefer? – Mats Petersson Jul 23 '15 at 21:31
2

@LightnessRacesinOrbit maybe not in the sense of a perfect language, but as a useful tool it most certainly is. – Captain Giraffe Jul 23 '15 at 21:34
1

@CaptainGiraffe: Supporting backward compatibility as a fundamental may be useful, but mixtures of C and C++ code are never a "strong point". – Lightness Races in Orbit Jul 23 '15 at 21:48
2

@LightnessRacesinOrbit Indeed, but I find Mats' argument convincing. – Captain Giraffe Jul 23 '15 at 21:57
@LightnessRacesinOrbit: I modified the wording a little bit to clarify (and added a few examples of "useful C-code" that is [relatively] easy to interface to C++, compared to other languages) – Mats Petersson Jul 23 '15 at 21:59
@CaptainGiraffe: I think I used to, though I've since grown out of it ;) – Lightness Races in Orbit Jul 23 '15 at 23:08

score 2 · Answer 2 · answered Jul 23 '15 at 22:31

Well, the ability to declare functions within function bodies is inherited from C so, by definition, there is a reason involving historical and backward-compatibility reasons. When there is likely to be real-world code which uses a feature, the argument to remove that feature from the language is weakened.

People - particularly those who only use the latest version of the language, and are not required to maintain legacy code - do tend to under-estimate how strong an argument backward compatibility is in C++. The original C++ standard was specifically required to maintain backward compatibility with C. As a rough rule, standards discourage removing old features if doing so is likely to break existing code. It can be done, however, if the only possible usage causes a danger that cannot be prevented (which is reason for removal of gets(), for example).

When maintaining legacy code there are often significant costs with updating a code base to replace all instances of an old construct with some modern replacement. A coding change that may be insignificant for a hobbyist programmer may be extremely costly when maintaining large-scale code bases in regulatory environments, where it is necessary to provide formal evidence and audit trail that the change of code does not affect ability to meet its original requirement.

There are certain programming styles where it is useful to be able to limit the scope of any declarations. Not everyone uses such programming styles, but the reason such features are in the language is to allow the programmer the choice of programming technique. And, whether advocates of removing such features like it or not, there is a certain amount of code which uses such constructs usefully. That significantly weakens the case for removing the feature from the language.

These sorts of arguments will tend to come up for languages that are used in large-scale development, to develop systems in regulatory environments, etc etc. C and C++ (and a number of other languages) are used in such settings, so will tend to accumulate some set of features for "historical" or "backward compatibility" reasons. It is possible to make a case for removing such features by providing evidence that the feature is not in real-world use. But, since the argument is about justifying a negative claim, that is difficult (all it needs is someone to provide ONE example of continuing real-world beneficial usage and suddenly a counter-example exists which supports the case for keeping the feature).

Why allow function declarations inside function bodies

2 Answers2