With NamedTuple keyword arguments and constant propagation pull requests both open, it sounds like keyword arguments will soon be type stable and fast. Does this spell the end for optional arguments? Keyword arguments have several advantages:
Disadvantages:
I am really looking forward to those merges. I have been holding back on keyword arguments for performance reasons till now, which was unfortunate.
Optional positional arguments are still quite useful. I’m not clear why we would get rid of such a basic and standard language feature.
What is an example of an interface where it would make more sense to use optional arguments than keyword arguments?
Anything with a splat (hcat).
I am not sure why you think this. Many languages have both just fine.
One, or at most two, optional arguments are kind of a sweet spot in most contexts when there is nothing else to parametrize. For 2+, it is usually better style to use keywords. There is place for both.
Oh sorry I meant what is an example where it makes more sense to use optional arguments than positional arguments. I’m totally fine with splats.
Which languages support both? Just out of curiosity
Okay, the answer is still APIs where you splat some number of arguments. Those don’t need to be named by the user, you just need N of them in a row.
Many. It is more or less the norm these days. See the intersection of
But you can splat named tuples as well, no?
Ok yeah thats basically everyone
Notably C# isn’t listed as having optional arguments
Why would you require a name for each one?
Readability?
Extensibility?
Reorderability?
No. max(2,4,6,8) (max(x...)) is objectively simpler, more readable, and more extendable than max(x1=2,x2=4,x3=6,x4=8) (@generated function max(;kwargs...)), and it’s easier to implement.
In the packages I develop I also use optional arguments as fundamental parameters for an algorithm that are crucial for it. I use keyword more like things that fine-tune the algorithm.
For example, an initial condition would be optional argument since it can be automatically generated randomly but the outcome depends crucially on it. On the other hand, some kind of tolerance level is a keyword argument.
I like it very much this way, and it allows me to keep this behaviour choice consistent across functions. So I am happy that I can use both arguments and keyword arguments.
Maybe I’m still being dense. It looks like max is defined as
($op)(a, b, c, xs...) = afoldl($op, ($op)(($op)(a,b),c), xs...)
Those aren’t the kind of optional arguments I’m thinking of. I mean optional arguments in the sense of
join(strings, delim = "", last = "")
Which I think would make more sense as
join(strings; delim = "", last = "")
Why would you want your user to have to constantly use rstrip(s, chars=mplah_mplah) instead of just rstrip(s, mplah mplah)…? I would definitely not want this for functions that have less than 5 arguments
I guess I’m in general a fan of readable code. I think that rstrip(s, chars=mplah_mplah) is much more readable in case you forget what second argument is supposed to be (number of characters to split? A regex expression?). It is also much more flexible in terms of being able to go back and add other keyword arguments in any order without breaking code (I think?)