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

[Lionello Lunesu]

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?

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?

"The primary aim of this proposal is to aid in readability and 
the implementation of tooling."

This primary aim can be achieved with less syntax and rules:
* No new parameter syntax
* Make argument names optional using the proposed `Identifier : 
ConditionalExpression` syntax, with a compiler error on 
identifier mismatch

Mentioning argument names at the call site improves readability 
and code robustness. This doesn't allow reordering, but also 
avoids any expectation of overloading based on parameter names.

Lio.