However, it seems to me that you could entirely resolve this problem by having true keyword arguments and default arguments must be keyword arguments; they can not be supplied positionally. If you then want some syntactic sugar in your API, you can then do what the author suggests as a solution to default values and supply variants that explicitly pass "defaults" to the master function.
Keyword arguments allows defaults while still allowing exact control over the arguments, exact control over the "overload selected" without explicit variants, and the ability to supply explicit variants if you want API ergonomics. The only downside I can see (relative to the solutions presented by the author) is that you have to write some extra argument names when passing non-default values to any variants that do not trivially pass them through, but that is a pretty minor cost especially with a IDE that can autocomplete the keywords, and it provides extra useful documentation to the maintainer and client, so it is not even all bad.
def name(positional_only_parameters, /, positional_or_keyword_parameters, *, keyword_only_parameters):
pass
I quite like that approach.
- Defaults avoid having to duplicate the rest of the function (everything outside the body braces) just for the sake of an additional parameter. It might not be a big deal for reset() which is simple and only takes one argument anyway, but for other functions it can be a lot of boilerplate to keep in sync with the main overload: everything from the documentation, templates, parameter names, parameter types, etc. needs to be duplicated and kept in sync.
- Without default arguments, you lose the ability to capture parameters by-value with guaranteed move/copy elision. You have to capture by reference and then construct at least one instance that you otherwise be able to elide. Sure, you don't need that performance all the time, but that's not the point. The point is there are times when you do.
- "Go to definition" in your IDE goes directly to the place you care about; "find all references" finds all references directly.
- Optionals are just way easier to read. Otherwise every reader or maintainer must read every other parameter and ensure they're all forwarded 1:1 without side effects to understand if the semantics of the call are identical with the optional parameter supplied explicitly.
If you want to create a proxy function to a function that has default arguments, and want to transparently allow the "default" features to be used from the wrapper function as well, then you have to duplicate the default value in the signature of the wrapper function.
There are other problems, for example due to the nature of function call syntax with positional arguments.
The solution is: Use a struct to hold default values.
struct FooDefaults
{
int arg1 = 3;
int arg2 = 7;
}
void FooFunction(int x, int y, FooDefaults defaults)
{
...
}
void usage_code(...)
{
int x = 1;
int y = 2;
FooDefaults defaults;
defaults.arg2 = 9;
FooFunction(defaults);
}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.)
void FooFunction(int x, int y, optional<int> optarg1 = {}, optional<int> optarg2 = {}) {
int arg1 = optarg1.value_or(3);
int arg2 = optarg1.value_or(7);
}
void usage_code() {
FooFunction(x, y, {}, 9);
}
I do like the struct as well, but it is still not ideal if you want to use initializers. I.e this doesn't work in C++:
FooFunction(x, y, {.arg2 = 9});
Works better with optional (and converting everything to a struct):
FooFunction({.x = x, .y=x, .arg1 = nullopt, .arg2 = 9});void foo(int a = 1) {}
Now you ship this in a DLL, but realize the default was bad, so you change it to 2 and ship the new DLL. Well, the 1/2 isn't in the DLL at all. It's only in the header file. So everyone must recompile. Fun times.
Of course, the same problem applies in other languages if a constant value changes. A preprocessor macros in C, for example. It's all about non-manifest interfaces and "making things easier" so that any idiot can write software (so they do). Public APIs can be hard when the public is imperfect.
print_square('*');
print_square(fill='*'); // Hypothetical fix
> 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);
public int doStuff(int a, int b) { //some code }
public int doStuff(int a) { return doStuff(a, 7);} // so b=7 by default.
No need to repeat actual business logic code.
Of course that gets complicated if there are many parameters with default values.
My pet peeve is reading code and trying to reason about
foo(true, 1, 1, null, “cupcakes”) foo(bake: true, batches: 1, boxes:1, frosting: null, type: “cupcakes”)Also frosting can’t be null when type is cupcakes. We found a bug.