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

[Yuxuan Shui]

On Saturday, 16 February 2019 at 23:56:45 UTC, Vladimir Panteleev 
wrote:
> 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.

Good point.

>
>> 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.

It's not my favorite either. But I feel it is the best we can do
at the moment.

>
> 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 don't see why forward declaration won't work for templated 
functions.

And I don't quite understand why there might be linking problems. 
Can
you give an example?

>
> 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);

So, there are a couple (two) problems with this:

1. the parameter list might just get longer and longer, making 
the documentation
    verbose and hard to read.
2. The user can use any combinations of the aliases (e.g. (x, y, 
w, height), (x, y, width, h) are all valid), this is not 
necessarily helpful to readability.

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

deprecated forward declaration could work. I will make that 
explicit in the next revision of this DIP.

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

You raised good points, thanks.