The problem with this reasoning is contained in this:

> to force programmers to consider the API and the values they are passing for each argument rather than silently accepting defaults they may not be aware of.

All you will force poor coders to do will be to fudge the arguments until the code "works". This is actually worse than the default arguments scenario, because the defaults are more likely to be acceptable than the first value the coder stumbles upon that makes the function go.

Taking a line from the Python philosophy: "explicit is better than implicit."

Why would it be hidden? It's a default, customizable behavior. If you don't need to customize it you don't and there's no reason to task you with putting the method in the state which is going to be needed 9 times out of 10.

> and indeed if the default value is flipped in the header file the caller could change behavior with no code change at the call site!

And if the whole implementation is replaced by formatting your hard drive, the caller could change behavior with no code change at the call site!!

> Taking a line from the Python philosophy: "explicit is better than implicit."

You're probably misapplying/misunderstanding things, since Python is one of the languages making the most use out of default values and with extremely strong first-class support for them.

So? I don't understand what the problem is. The very act of packaging code in a function is one that hides information about what that function does. And suppose you don't provide a default for the `strict` argument. Unless you're using a language with named function arguments (or an approximation thereof like Objective-C), you won't know that the `false` you see in the argument list means "don't use strict" anyway until you read the documentation. And once you're reading the documentation, this all becomes moot.

> There is no indication at the call site what mode it is operating in, and indeed if the default value is flipped in the header file the caller could change behavior with no code change at the call site!

Yeah, and if you reorder your function parameters, or rename your function, or change the "strict" argument to "lax", or an infinite number of other changes, you would also change behavior with no change at the call site. The solution in each case is "don't do that".

Again, the act of packaging code in a function is one that makes it so that changes in behavior can happen independent of the call site. Sometimes it works to your advantage. Sometimes it doesn't. That's just life.

"What a function does" is encapsulated in that function's name. So for example you could have:

  GoToTheStore();

  Go(store);

Once you have default parameters, the behavior of the function is no longer fully explicit, because some of the function's input comes from somewhere else:

  Go();  // Goes to the store by default.

Also, code itself is the most reliable documentation, but looking at the implementations of the functions involved won't reveal this extra input; only cross-referencing the header files will, which requires more mental effort for your reader.

I would like to suggest that the function's name should tell you the result (going to the store) and not have anything to do with what the function does (walk, bike, drive, fly) to get that result. Parameters could restrict how the function gets the result. In which case, a default parameter of ANY means no restriction and makes perfect sense with actually less mental effort for the reader.

  GoToTheStore();  /* get me to the store */

  GoToTheStore(ANY);   /* does ANY refer to any store?  */

  GoToTheStore(DRIVE);  /* I'm feeling lazy, and don't want to walk. */

I agree with mistercow: default arguments are, on the whole, a Good Thing. Think of them as a restricted form of overloading which requires (much!) less code to be written.

Obviously they can be misused, but again, that's the nature of programming (and especially of C++). Sane default argument conventions make code easier to read and write.

Your argument makes no sense; the "this" pointer is just a function parameter, and the whole point of a function is that the arguments aren't fixed until the function is called. No part of this is implicit.

> The identity of the function to be executed is hidden from the caller.

The function is named at the call site along with all input to that function (unless you use default arguments). This also is not hiding: every part of the function and its input is explicit.

Much better arguments for your case would be overloaded operators and implicit conversions, both of which happen without an explicit information at the call site. But it's no coincidence that both of these are forbidden by the Google Style Guide also.

The reason I would tend to use default arguments in Python and C but not in C++ would be that it can get confusing if you throw in C++'s function overloading. A function by its very nature can't help but have default behavior, and if someone realizes they need to override the defaults they'll probably end up in the documentation or function definition or some other place that will let them realize they can adjust the defaults.

I am surprised this is an issue at Google.

Just because they have more stringing hiring practices doesn't make their engineers some superhuman level of programmer.

It seems that many engineering decisions are made at google, to minimize the amount of damage a particular programmer can do. This suggests that while Google does/may have some very good people running the place, they also have quite a few programmers whom are mediocre at best.

These choices are about building an environment that forces a programmer to do things the right way, rather then expecting them to do such on their own.