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

[rikki cattermole]

On 11/09/2019 5:53 PM, Lionello Lunesu wrote:
> On Tuesday, 10 September 2019 at 09:06:23 UTC, Mike Parker wrote:
>> This is the feedback thread for the second round of Community Review 
>> for DIP 1020, "Named Parameters":
>>
>> https://github.com/dlang/DIPs/blob/c723d8f4e3ac2d5bcaf8cdff87e1507f09669ca6/DIPs/DIP1020.md 
>>
> 
> I can't seem to find the rationale for the necessity of a parameter 
> syntax? As a library writer, when would I annotate a parameter with 
> `@named`? Does adding `@named` *require* naming the parameter? The DIP 
> notes a new trait to find named vs unnamed parameters, but is that the 
> *reason* for the new syntax or a handy side effect? Couldn't the regular 
> UDA trait be used (or extended) to find `@named` or any other UDA for 
> that matter?

A named parameter must include a name yes. Good catch.

The trait(s) is listed under "Supporting Syntax". It supports the rest 
of the DIP and while useful I wouldn't call it a handy side effect or a 
reason for design choices were made.

Its a simple way that does not require much in the way of changes to the 
language or would take very long to implement to get the named parameter 
names on a template (for e.g. functions that is a side effect for 
consistency reasons).

> If I assume there's a good reason for having this opt-in for parameters, 
> wouldn't this then require a lot of churn for library writers, with 
> diffs adding just `@named` to parameters and no other code changes?

Nobody is forced to use it.

I would recommend to incrementally add it, as the API designs allow for 
it, and not just add it because it exists.