Discussion Thread: DIP 1030--Named Arguments--Final Review

[Steven Schveighoffer]

The biggest problem I had with this DIP still remains -- You cannot 
forward the "namedness" of parameters to a subtype.

Consider the following, which is supposed to wrap a subtype:

struct S
{
     int foo(int bar) {...}
}

struct LogCalls!T
{
    private T _wrapped;
    auto ref opDispatch(string f, Args...)(auto ref Args args)
    {
        log("Calling ", f);
        mixin("return " ~ f ~ "(args);");
    }
}

This works today and can be used to reasonably wrap everything that T 
can do.

But with this named parameters DIP, then we have problems:

// S s;
LogCalls!S s; // I want to log things temporarily

s.foo(bar: 5); // error

I think this is important to solve. Because you have types whose "API" 
is "I will wrap everything this type does", and this breaks the promise 
with no possibility of a fix. While everything that compiles today will 
compile tomorrow, code will migrate to using named args, and then you 
can't use these wrappers, or you have to explicitly forbid users from 
using named arguments.

Discussed here: 
https://forum.dlang.org/post/mailman.1114.1581363532.31109.digitalmars-d@puremagic.com

And this was my reply at that time:
https://forum.dlang.org/post/r1uaph$2pkl$1@digitalmars.com

A possible solution is to accept a string[] arg as the first parameter 
in opDispatch, so the names can be captured. This also allows an opt-in 
so current opDispatch cannot be called via named parameters.

Another possible mechanism is to provide a __traits call to get argument 
names, but the issue here is that then you can call code that isn't 
written to handle named args with named args and the right thing might 
not happen.

Another possibility is to provide a second variadic parameter e.g.:

opDispatch(string f, Args..., string[] names...)(Args args)

Where names will be filled in with the names provided by the caller, or 
null if not provided.

This is also a nice opt-in, as it doesn't compile today.

-Steve