DIP 1020--Named Parameters--Community Review Round 2

[rikki cattermole]

On 11/09/2019 4:39 AM, Yuxuan Shui wrote:
> I scribbled down a few points as I was reading through the DIP
> 
> 1.
> 
>> Parameters must be marked as accepting named arguments, otherwise 
>> there will be no way to determine which overload to resolve.
> 
> I am little confused by this statement. Since later in the document you 
> state that "Named parameters must not modify symbol or overload 
> resolution", that means whether a argument is marked or not should have 
> no impact on overload resolution?
> 
> 2.
> 
>> named parameters must be opt-in.
> 
> Then all the argument against DIP1019's opt-in-ness also applies to this 
> DIP.

Yes it does, but it buys you a lot more functionality compared to DIP1019.

> 3.
> 
>> Each named parameter must be marked
> 
> Can you discuss the pros and cons of marking each individual parameter 
> vs marking functions?

Added: https://gist.github.com/rikkimax/91d0291da30d6ed161c6d3fa89868883

Typically you want to mix naming parameters and unnamed.
They are complimentary of each other.

E.g.

void func(int[] args..., @named bool flag);
func(1, 2, flag: false); // ok

A concrete example got removed during editing since this covers it but:

EmailStatus isEmail(Char)(const(Char)[] email, CheckDns checkDNS = 
No.checkDns, EmailStatusCode errorLevel = EmailStatusCode.none)

is a good example (checkDns and errorLevel could be named parameters) 
from https://dlang.org/phobos/std_net_isemail.html#.isEmail

> 4.
> 
>> The first addition is the isNamedParameter trait
> 
> Why couldn't we use getAttributes for this?

That is for UDA's and does not support function parameters.

isNamedParameter is modeled after an existing trait and will be used 
almost identically to it.

> 5.
> 
>> Overload resolution for symbols (for function and template 
>> declarations) is performed without taking named parameters into account
> 
> Ah, I guess this answers point (1). But this also means named parameters 
> _does_ affect overload resolution, since functions with/without named 
> parameters will be evaluated differently during overload resolution.

It depends on your perspective I guess.

See point 6 for example.
Basically the existing algorithms continue to do the same thing as they 
do now and ignore the new argument/parameter type.

> Also, I assume this is needed because you want to support reordering?
> 
> 6.
> 
>> alias Bar2 = Bar!(int, Flag: 0); // error: matches both declarations
> 
> I think this has the potential to cause a lot of confusion.

struct Bar(T) {
}

is the same as

struct Bar(T, @named int Flag) {
}

When doing symbol resolution (since the named parameter isn't accounted 
for, only verified after symbol/overload was chosen).

> 7.
> 
>> Template declarations that have named parameters expose the named 
>> parameter as a member of the template.
> 
> Ah, this is very nice.

Thanks!