Default Arguments vs Overloading? - c++

Question

In WG21 N0131 Bill Gibbons states:
default arguments are often considered an anachronism because they can be replaced with overloaded functions
I understand that a single function like:
void f(T t = t0, U u = u0);
can be replaced by the three overloads:
void f() { f(t0); }
void f(T t) { f(t, u0); }
void f(T t, U u);
but what I don't understand is why the latter should be preferred over the former? (That is what he means by "anachronism", right?)
There's some related discussion in the Google styleguide here: Google C++ Styleguide > Default Arguments, but I don't see how it answers the question or supports Gibbons claim.
Anyone know what he's talking about? Why are default arguments considered an anarchronism?

Answer 1

From my own experience, the problem is that of violating the principle of least astonishment when interacting with other language features. Let's say you have a component that uses f a lot. I.e. you see this in plenty of places:
f();
From reading it, you assume you have a function that takes no arguments. So when you need to add interaction with some other component that has a registration function:
void register(void (*cb)());
you do the obvious thing...
register(f);
... and you immediately get a nice shiny error because the declared type of f is a function that takes two arguments. Wtf!? So you look at the declaration and understand... right...
The default arguments make your code behave a certain way via the compiler "fudging" the call site to make things work. It isn't really calling a function with no argument, but implicitly initializes two arguments to call the function with.
On the other hand, the overload set does behaves how one would expect. There is no "fudging" of the call site by the compiler, and when we try to register(f)... it works!

Answer 2

The one objective reason to prefer overloading
I've recently been presented an objective (well, what I think it is! :D) reason why one should prefer overloading to default arguments, at least when default values are non-builtin types: unnecessary #include directives in header files.
Default arguments should be an implementation detail, because you as the implementer take the decision of what argument to use on behalf of your client, if they don't provide it to you. Why should they be aware of your decision? So when you have a function declared like this
void doSomeWork(Foo, Bar = defaultBar);
you would really like defaultBar to be a "secret", not exposed to your includers.
At the moment you prefer default arguments, they you have to include in your header, all the headers that you need to be able to write defaultBar. How much can that cost to you?
Well, Bar could be a (reference or pointer to a) base class, and defaultBar is an object of a concrete class, so you're forced to include both the headers where one and the other classes are defined.
Or maybe Bar is std::function<bool(Foo const&, Foo const&)>, and its default value is actually an expression such as compose(std::less<>{}, convertToInt), you'd have the following in your header:
// ok with these
//#include "Foo.hpp" // in the code below you don't even need the definiton of
// Foo, so you could be happy with just it's forward header
#include "fwd/Foo.hpp" // this only declares Foo
#include <functional>
// but why these?
#include <boost/hana/functional/compose.hpp> // or alternative
#include "/path/to/convertToInt.hpp" // maybe this does bring with it Foo.hpp
using Bar = std::function<bool(Foo const&, Foo const&)>;
void doSomeWork(Foo const&, Bar = compose(std::less<>{}, convertToInt));
With overloads the header would be this
// ok with these
#include "fwd/Foo.hpp" // this only declares Foo
#include <functional>
using Bar = std::function<bool(Foo const&, Foo const&)>;
void doSomeWork(Foo const&, Bar);
void doSomeWork(Foo const&);
and only in the implementation, would you include the other headers too
#include "fwd/Foo.hpp"
#include "Foo.hpp"
#include <functional>
#include <boost/hana/functional/compose.hpp>
#include "/path/to/convertToInt.hpp"
void doSomeWork(Foo const& foo, Bar bar) {
// definition
}
void doSomeWork(Foo const& foo) {
doSomeWork(foo, compose(std::less<>{}, convertToInt));
}
Original answer
I would first of all refer to this article on FluentC++ which addresses this very question and gives a clear personal answer near to the top of the post:
By default, I think that we should prefer default parameters rather than overloads.
However, as the By default implies, the author gives merit to overloads in favour of default parameters is some peculiar situations.
My original answer follows, but I have to say: the article linked above did reduce substantially my repulsion for default arguments...
Given void f(T t = t0, U u = u0);, you have no way to call f with a custom u and letting t be the default t0 (unless you manually call f(t0, some_u), obviously).
With the overloads, it's easy: you just add f(U u) to the set of overloads.
So with overloads you can do what you can do with default arguments, plus more.
Besides, since with this question we are already in the land of opinions, why not mentioning the fact that you can re-declare functions by adding more defaults? (Example taken from cppreference.)
void f(int, int); // #1
void f(int, int = 7); // #2 OK: adds a default
void f(int = 1, int); // #3 OK, adds a default to #2
And the fact that the definition of a function cannot re-define a default argument if a previous declaration of the function defines it (for a pretty clear and understandable reason)?
void f(int, int = 7); // in a header file
void f(int, int) {} // in a cpp file correct
void f(int, int = 7) {} // in a cpp file wrong
Yes, maybe the default arguments are an "interface thing", so probably not seeing a sign of it in an implementation file is fine.

Answer 3

Anachronism means something that stands out for being in the present given that it is widely considered to be a thing of the past.
The rest of my answer is a matter of opinion... but the question itself supposes that there isn't a hard-and-fast "answer".
As for why default arguments are a thing of the past, there could be many examples.... the best one that comes to mind for myself however is that especially when writing a set of reusable functions, we want to reduce the potential for mis/incorrect use.
Consider the following:
void f(int i = 0, char c = 'A'){std::cout << i << c << std::endl;}
Now consider that someone attempts to use it as follows:
f('B');
They probably expected to see this output:
0B
What they get however is:
66A
Upon seeing the output they understand their mistake and correct it... but if you remove the default parameters and instead force the use of one of a couple of specific overloads that will accommodate a single parameter of either type... then you have made a more robust interface that provides what would be the expected output every time. The default arguments work... but they aren't necessarily the most "clear" in the case of development when someone forgets that if at least one argument is supplied in the function call, only the trailing arguments can be defaulted.
In the end, what matters is that the code works... but if you saw code with labels and goto statements, you'd be like, "oh really?". They work fine... but they can be misused. Switching languages to stress the subjective nature of the discussion in general... if JavaScript works well and provides so much freedom given the the nature of its variables having mutable type... why on earth would anyone want to use TypeScript? Its a matter of simplifying/enforcing proper reuse of the code. Otherwise who cares as long as it works...