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

Yuxuan Shui yshuiv7 at gmail.com
Tue Sep 10 16:39:04 UTC 2019

I scribbled down a few points as I was reading through the DIP


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


> named parameters must be opt-in.

Then all the argument against DIP1019's opt-in-ness also applies 
to this DIP.


> Each named parameter must be marked

Can you discuss the pros and cons of marking each individual 
parameter vs marking functions?


> The first addition is the isNamedParameter trait

Why couldn't we use getAttributes for this?


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

Also, I assume this is needed because you want to support 


> alias Bar2 = Bar!(int, Flag: 0); // error: matches both 
> declarations

I think this has the potential to cause a lot of confusion.


> Template declarations that have named parameters expose the 
> named parameter as a member of the template.

Ah, this is very nice.


Also, thanks for pushing named arguments forward!

More information about the Digitalmars-d mailing list