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

[12345swordy]

On Wednesday, 11 September 2019 at 14:33:37 UTC, rikki cattermole 
wrote:
> 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.
What good is named arguments if around 90% libraries don't 
support it?