On Thu, Feb 6, 2020 at 9:57 AM Henry Miller via Std-Proposals <
std-proposals_at_[hidden]> 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!
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1163r0.pdf

–Arthur