On Thu, Feb 6, 2020 at 9:57 AM Henry Miller via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
On Wed, Feb 5, 2020, at 2:05 PM, Edward Diener via Std-Proposals wrote:

> My own experience is that a highly flexible software library often
> entails the extensive use of default template and function arguments.

There is a group that will say long lists of parameters is bad, therefore we shouldn't make it easier to work with. I agree with the idea in theory, but the real world is messy and so I often end up with longer than wanted argument lists. Be prepared for this argument if you go farther.

Absolutely. The way I usually explain it is, "Defaulted function arguments are the devil." ;)
Show me a library that uses defaulted function arguments, and I'll show you a patch that removes all the defaulted arguments and makes the library easier to maintain and comprehend.

Defaulted function arguments were one of those historical features that made it easier to do "polymorphism" before C++ acquired more modern features such as function overloading and (especially) the ability to inline functions. Back in the '80s, it wasn't considered feasible to write two functions

int f(int x) { return 2*x; }
int f() { return f(0); }

since then a call to `f()` would cause the execution of two call instructions instead of just one. It was seen as more performant to write

int f(int x=0) { return 2*x; }

so that a call to `f()` could get expanded at the call site into `f(0)`, before codegen.
But once we got inline functions, this rationale went away forever.

Although I wish P1163 had gone the other way and `explicit`ified all (non-copy non-move) constructors, instead of de-`explicit`ing a bunch of them, P1163 remains a good example of how to disentangle the unintended effects of defaulted function arguments — and shows how a desire to be "clever" with defaulted function arguments can lead to unintended effects in the first place!

–Arthur