Today, Vikram Ojha asked via email:
I was just thinking why we removed “int” as default return type from C++ which was there in our traditional C type. Why we made such changes, is it to make language more safer?
Short answer: Because it’s ‘inherently dangerous’ in the words of the C committee.
For C++, see D&E (The Design and Evolution of C++) index “implicit int” which takes you to section 2.8.1. For C, see the C99 Rationale section 6.7.2 — interestingly, you can’t search for “implicit int” because that term isn’t used — this is where the string to search for is “inherent danger” :).
Cribbing from Bjarne’s writeup, “implicit int” was removed some 20 years ago for several reasons, including code clarity and in additional avoiding special cases, to simplify C++ code and/or the C++ grammar.
For example, what does this mean?
void f(const T);
In modern C++, it can mean only that f has a const parameter of type T that is unnamed.
If we had implicit int, this would be less obvious: Could it also be a const parameter of type int named T?
There are a number of other cases where just omitting the type, with the meaning that it’s a certain fixed type, makes the grammar and/or the program harder to think about than it should be. So the ability to do that was removed in both C and C++.
Sutter’s Mill 
While I think this is a good change which will improve readability without sacrificing to much flexibility, the int type is still special in some circumstances, for example when doing arithmetic operations on smaller-than-int types the operands are upconverted to int first.
Unnamed parameters are often used to indicate that the parameter is not used in the function. This means the compiler doesn’t have an additional identifier that it will flag as unused, and the next person to look at the code understands that immediately. Good parameter names do indeed make the code more readable, and if we’re using the name to indicate the role of the parameter, an unused parameter should have no name.
Parameters can be unused for good reasons. A function for a library callback may not use all the information the library provides. A function in a set of overloaded functions may have no use for one of the parameters.
In your ambiguous example, it seems to me an alternative language fix might have been to forbid unnamed parameters in the declaration of a function. After all, I seem to remember reading thirty years ago that named parameters were an important part of making C code “self-documenting” (which it was, compared to the e.g. assembler or Fortran which preceded it (directly, in my own workplace of that era)). Unnamed parameters evade this important mechanism. On the other hand, am I correct in recalling that C, too, permitted unnamed parameters in function declarations? If so, well, then, I’m egotistical enough to say that “it shouldn’t have” — since we would then have avoided this entire issue forevermore. If we simply stipulate that C did permit unnamed parameters, I can imagine the argument against forbidding them in C++ going something like, “But look at the enormous volume of existing code that would have to be changed!” — to which I say, “A one-time burst of pain is preferable to perpetuating an architectural error forever.”
Dear Herb Sutter,
how I can suggest a question for Reader Q&A. I did not find an email address of you on this page.
Thanks!
Sir am quite clear that why int as a default data type is removed as it can add confusion but why “int” as a default return type is removed is removed ?
Once Concepts makes it into the standard we can add an “implicit auto” rule. C++ will be that much closer to Perl ;)
@Motti: Fixed, thanks.
But think of the value of implicit “it”: seems that having would make easier to write tersely when matters. :)
Typo alert:
> If we had implicit it
“for small values of ‘n’ ” ;)