Problems with default function arguments (2020)

Let's be real, default arguments are most commonly used because the programmer is lazy and doesn't want to update the function call in 200 places.

> you can't pass the default values around, they can't flow in the code.

I see you worked very hard on those contortions just to find some way to call them dataflow ;)

The values can obviously be passed around just fine. The issue is duplication of their source of truth, not their inability to be passed around. And the duplication of the source is easy enough to fix - if you don't want to hard-code them then you can just make a static function (or constant) that returns them so callers can refer to that same value without duplicating the source of truth. No need to throw entire the baby out with the bathwater.

(And the struct solution is an alternative to unnamed arguments, not to default arguments per se. It has its own advantages and disadvantages.)

This may just be my inexperience with the intricacies of C++, but it seems like a decent number of the problems raised here could be fixed by allowing one to name default args like proper keyword arguments. Consider the first issue discussed and how naming the argument just fixes it:

  print_square('*');
  print_square(fill='*'); // Hypothetical fix

It also seems to be an issue exacerbated by C++ implicitly converting a char into an int.

> The client programmer doesn’t want a “puzzling” print_square(x) that treats x sometimes as a side length and sometimes as a fill character!

This is also fixed if C++ allowed you to name keyword arguments explicitly (and didn't sometimes implicitly convert types, but that's baked in pretty hard by now).

> The “boolean parameter tarpit”

Again, imagine how much more understandable it would be if you could write:

  doTask(task1, 100s, catchStderr=true);

I wonder whether the author would change their stance on default args if they were made to be more usable.

To be more precise you can't read default values from the source of truth, which is the parameter list. There is syntactically no way, and they aren't materialised in any accessible way at compile time.

> you can just make a static function (or constant) that returns them so callers can refer to that same value without duplicating the source of truth

Oh, but now you have duplicated it. Maybe not a value literal, but you still have to synchronize the default value expression (constant reference or whatever) between the parameter list and every other place that is interested.

And at any place that is not interested in such data you still have to meticulously forward the precise list of default values in the right order to a final consumer of the data.

You cannot

    void func(int x = 1, int y = 2, int z = 3);

    void usage()
    {
        int x = gimme_default(func, x);
        int y = gimme_default(func, y);
        int z = gimme_default(func, z);
        ...
    }

You also cannot

    void func(42, PASSDEFAULT, -1);

As you explained you can

    constexpr int FUNC_DEFAULT_X = 1;
    constexpr int FUNC_DEFAULT_Y = 2;
    constexpr int FUNC_DEFAULT_Z = 3;

    void func(int x = FUNC_DEFAULT_X, int y = FUNC_DEFAULT_Y, int z = FUNC_DEFAULT_Z);

    {
        int x = FUNC_DEFAULT_X;
        int y = FUNC_DEFAULT_Y;
        int z = FUNC_DEFAULT_Z;
        ...
    }

but that's already too painful for me to write, when the more realistic setting is that there is also

    void func_variant1(int foo, int x = FUNC_DEFAULT_X, int y = FUNC_DEFAULT_Y)
    {
         do_foo(foo, x, FUNC_DEFAULT_Y);
         func(x, y, FUNC_DEFAULT_Z);
    }

    void func_variant2(int foo, int bar, int x = FUNC_DEFAULT_X, int y = FUNC_DEFAULT_Y, int z = FUNC_DEFAULT_Z); // etc

There is already significant boilerplate / repetition and I have a sense that there will be a new FUNC_DEFAULT_W coming soon that has to be inserted in 53 places. This is the textbook application for structs, which can abstract over sets of primitive data items.

Code that makes significant use of default arguments always has that unstable, arbitrary sense to it, with function parameter lists that grow too long, and it always seems to be badly structured and fragile. I cannot prove it formally but I have the hair to prove that I've spent months of my life refactoring such code.