@Tamas_Papp I agree, at this level, the discussion is too generic. But then again, this is relatively easy to address: what are the main approaches to dealing with methods with optional arguments? Are there any other schools of thought? Is Julia’s approach equally common?
Doing a bit more soul searching during breakfast, I’m actually starting to think that this approach might not be entirely consistent with Julia itself - and that arity should, maybe, be an important part in Julia’s implementation too.
The reason is that in Julia, a function in invoked by passing it a Tuple of arguments. A Tuple, by definition, has its type provided by the number and types of its elements.
When I define a method, I define the type of Tuple it should be invoked with. So in this line of thinking, the method’s signature is defined in relation to the type of the Tuple of arguments it takes. Basically we have a method that is defined by its name the fact that it takes a number of exactly x arguments of exactly the types A, B, C, … .
In this reasoning, Julia defining other methods of different arity and types of its arguments Tuple, means constructing completely different methods altogether, with completely different signatures.
So why not always have a fixed method signature (in terms of the type of its Tuple of arguments – so arity and types) and instead have the Tuples that can be constructed with optional arguments?
I hope I managed to explain properly: it’s basically about having the type of the Tuple of arguments a strict part of a method’s signature and not generating methods that take different types of Tuples. Instead the Tuple itself would be more flexible, maintaining its type but accepting default arguments when constructed.
This could be a dedicated subtype of Tuple, like for example MethodArgumentTuple. And when defining methods with optional arguments, instead of generating methods for all the combinations of arguments, Julia would create a new instance of MethodArgumentTuple that would always have the same type (x elements of type A, B, C, …).
So no more baz but always baz{MethodArgumentTuple{A, B, C}} and the Tuple itself would provide the default arguments.
I guess it’s a variation of baz(::String) with a different approach: it’s not the function but the Tuple of arguments providing the values of the optional arguments.