DIP 1030-- Named Arguments--Formal Assessment

[Q. Schroll]

On Thursday, 8 October 2020 at 14:05:14 UTC, Andre Pany wrote:
> how to this new feature interact with opDispatch? Will there be 
> any possibility to extract the argument names in opDispatch?

Good catch. The DIP doesn't mention opDispatch and it's probably 
too late to change. I also don't really see a non-breaking way to 
tell opDispatch about parameter names.
Giving opDispatch a string[] of named arguments' names (with "" 
for a name-less argument) would probably do the job, but it's a 
breaking change.

A different solution would be a new operator method called 
`opDispatchNamed` or alike that does exactly that. However, 
opDispatch is designed to be used when `c` in expr.c cannot be 
resolved, where expr.c(args) is a special case where `c` happens 
to be "something callable".

I'd say, the problem should be solved on a more general level: 
function templates *in general* (opDispatch included) should have 
a way to get named arguments' names. One possibility would be a 
magic __ARG_NAMES__ that returns a compile-time string[] that 
contains that names, like __FILE__ and __LINE__ at call site if 
used as a default parameter. So you'd use it like:

     auto opDispatch(
         string methodName,
         string[] argNames = __ARG_NAMES__,
         T, Ts...
     )(T arg, Ts args)
     {
         // argNames[0] will be "arg" always since it's not an 
pack.
     }

That way, it could be non-breaking and more useful.