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

[Yuxuan Shui]

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.

3.

> Each named parameter must be marked

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

4.

> The first addition is the isNamedParameter trait

Why couldn't we use getAttributes for this?

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.

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.

7.

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