DIP 1020--Named Parameters--Community Review Round 2
alexanderheistermann at gmail.com
Wed Sep 11 15:12:32 UTC 2019
On Wednesday, 11 September 2019 at 14:33:37 UTC, rikki cattermole
> On 11/09/2019 5:53 PM, Lionello Lunesu wrote:
>> On Tuesday, 10 September 2019 at 09:06:23 UTC, Mike Parker
>>> This is the feedback thread for the second round of Community
>>> Review for DIP 1020, "Named Parameters":
>> 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
More information about the Digitalmars-d