DIP 1019--Named Arguments Lite--Community Review Round 1

[Vladimir Panteleev]

On Friday, 15 February 2019 at 12:56:45 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community 
> Review for DIP 1019, "Named Arguments Lite":
>
> https://github.com/dlang/DIPs/blob/23ef47a94e0fdd5ddc4b2f6b2f4dcfd3c1f43aa6/DIPs/DIP1019.md

Named arguments is the #1 missing language feature in my personal 
wish list. It allows drastically improving the readability of 
code in many situations. With it, we can also do away with the 
awful Flag!"enableSomething" enableSomething / 
Yes.enableSomething templates. So, thank you for working on this.

> For example, in one potential library-only solution, it is 
> necessary to call functions like so:

> args!(add, a=>1, b=>1);

There is another big problem with this approach: you cannot do 
a=>a, b=>b etc. The compiler will pick up the fake lambda 
parameter instead of the variable from the outer scope. This is a 
pain because you will very often see fun(foo=foo, bar=bar) in 
idiomatic Python code.

> Opt-in: Calling a function with named arguments is opt-in on 
> the callee side.

@named is not the best idea. I don't want to have to check every 
time if the library author remembered to slap @named on the 
function I want to use named arguments with. Making it opt-in 
will probably mean that there will be people who use it and those 
who don't, and libraries written by users who don't will just 
cause frustration by those who do; and, for people who do, they 
might as well just slap it on everything, further contributing to 
attribute bloat. Also, the decision to use named arguments 
depends as much on the function as on the call site (e.g. how 
important is code readability vs. terseness in that particular 
piece of code). I'd be just too tempted to patch the compiler to 
enable it for everything.

Generally, I do not buy the lock-in arguments, now or 10 years 
ago when Don shut the idea down the first time. I think it is 
enough to give library authors a way to provide aliases to old 
parameter names, so they have freedom to rename the parameters 
without breaking code using named arguments.

I'm not sure if forward arguments is the best approach for this, 
seems very brittle - you don't update all signatures correctly, 
and suddenly some users of your library get hit with linking 
errors. And, what about templated functions?

I think allowing alias in parameter lists would be worthwhile, 
e.g.:

void drawRect(int x, int y, int width, int height, alias w = 
width, alias h = height);

Bonus if "deprecated alias" is allowed and works as expected.

Sorry, I'm jumping late into the discussion, so the above might 
have been already discussed.