> If you make this parameter have a default, it would be easy to use this function (or read code that uses it) without even realizing that the function can operate in more than one "mode."
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.
> The very act of packaging code in a function is one that hides information about what that function does.
"What a function does" is encapsulated in that function's name. So for example you could have:
GoToTheStore();
If you want to make a function more generic, you can make some aspects of the function's behavior depend on arguments. So an equivalent call of a more generic function could look like:
Go(store);
Both of these are equally explicit; the first has its behavior fully specified by the function itself, the second has its behavior fully specified by a combination of the function name and its argument.
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.
This is both unnecessary (both of the previous options are very usable alternatives) and needlessly implicit. It makes program logic more difficult to follow because you need to be aware of the implicit defaults to fully understand the data flow.
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.
> "What a function does" is encapsulated in that function's name.
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 */
vs
GoToTheStore(ANY); /* does ANY refer to any store? */
but when necessary
GoToTheStore(DRIVE); /* I'm feeling lazy, and don't want to walk. */
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.