DIP 1020--Named Parameters--Community Review Round 2
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
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
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
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