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

[Vladimir Panteleev]

On Sunday, 17 February 2019 at 00:27:42 UTC, Yuxuan Shui wrote:
> It's not my favorite either. But I feel it is the best we can do
> at the moment.

Sorry, but I will vote against a DIP with @named. With no 
guarantee that the opt-in will ever become opt-out or always 
available, the feature IMO will not carry its weight due to the 
problems I mentioned.

> I don't see why forward declaration won't work for templated 
> functions.

Will you need to expand the implicit template declaration (R 
fun(A)(A a){} => template fun(A) { R fun(A a) {} })? Or will the 
compiler need to detect that templates are part of the overload? 
I would suggest to consult with a DMD frontend expert to make 
sure the DIP is not overly difficult to implement.

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

@named:
int add(int a, int b)
{
     ...
}
int add(int c, int d);

Let's say you want to add an optional argument to add.

@named:
int add(int a, int b, int c = 0)
{
     ...
}

but you forget to update the other forward declaration to match.

You will not get a compiler error. You will not get a linking 
error if you never used the second declaration. But, a user using 
your library will now get a linking error if their code used the 
other declaration.

I realized another problem after I sent my post: This approach is 
not usable for interface methods, and abstract methods (which may 
or may not have a body).