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

All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on September 24, or when I make a post declaring it complete.

At the end of Round 2, if further review is deemed necessary, the DIP will be scheduled for another round of Community Review. Otherwise, it will be queued for the Final Review and Formal Assessment.

Anyone intending to post feedback in this thread is expected to be familiar with the reviewer guidelines:

https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

*Please stay on topic!*

Thanks in advance to all who participate.

On 9/10/2019 2:06 AM, 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

For reference here's the round 1 thread:

https://digitalmars.com/d/archives/digitalmars/D/DIP_1020--Named_Parameters--Community_Review_Round_1_325299.html

>Different options for opt-in named parameter syntax have been proposed and discussed in the D programming language community. DIP 88 proposed a colon to denote a named parameter, DIP 1019 originally proposed the use of the @named function attribute, and this DIP originally proposed that angle brackets be used to denote named parameters. After feedback from the first round of review, this DIP has been amended to propose an new @named attribute with which to annotate parameters rather than functions.

>struct Map(@named alias Function, @named InputType, @named ElementType)

As a C# programmer which has this feature too, this is excessively noise in contrast.

Wouldn't be easier to go with Opt-Out (Or In) with a flag on Compiler level?

S.

On 10/09/2019 11:51 PM, SashaGreat wrote:
>> Different options for opt-in named parameter syntax have been proposed and discussed in the D programming language community. DIP 88 proposed a colon to denote a named parameter, DIP 1019 originally proposed the use of the @named function attribute, and this DIP originally proposed that angle brackets be used to denote named parameters. After feedback from the first round of review, this DIP has been amended to propose an new @named attribute with which to annotate parameters rather than functions.
> 
>> struct Map(@named alias Function, @named InputType, @named ElementType)
> 
> As a C# programmer which has this feature too, this is excessively noise in contrast.
> 
> Wouldn't be easier to go with Opt-Out (Or In) with a flag on Compiler level?
> 
> S.

That would require a different design and I am not sure that it would be a good design element to incorporate.

I am happy to consider other options (@named was an option that was proposed in CR 1 that got a bit of support), however I am unsure if there is a better design waiting to be discovered.



In the example you referenced, the example in question over uses named parameters imo, for the purposes of demonstrating what it is capable of.

If that was a real example it should look somewhat like:

```
auto map(alias Function, InputType)(InputType input) {
	return Map!(Function, InputType)(input);
}

struct Map(alias Function, InputType,
	@named ElementType = ElementType!InputType)
```

Actionable list with this example listed on it is available here: https://gist.github.com/rikkimax/91d0291da30d6ed161c6d3fa89868883

On Tuesday, 10 September 2019 at 12:37:27 UTC, rikki cattermole wrote:
> On 10/09/2019 11:51 PM, SashaGreat wrote:

I have addition:

@named("arg") should accept string as named param name:
when arg is absent - use real param name
when arg is exists - use "arg" as param name for named param (phew!)

void func( @named("longBeautyName") int val ) {
  // I can use "val" here
  someGlobal = val;
}

// but when u use named param u should set longBeautyName
func( longBeautyName: 123 );

On 11/09/2019 1:27 AM, a11e99z wrote:
> On Tuesday, 10 September 2019 at 12:37:27 UTC, rikki cattermole wrote:
>> On 10/09/2019 11:51 PM, SashaGreat wrote:
> 
> I have addition:
> 
> @named("arg") should accept string as named param name:
> when arg is absent - use real param name
> when arg is exists - use "arg" as param name for named param (phew!)
> 
> void func( @named("longBeautyName") int val ) {
>    // I can use "val" here
>    someGlobal = val;
> }
> 
> // but when u use named param u should set longBeautyName
> func( longBeautyName: 123 );

I quite like the syntax for this semantic.

However I am unsure of its beneficial nature.

This semantic would cover renaming and give greater freedom to the API creator, but it would require some changes that complicates introspection even in the most basic of use cases.

Once function bodies are removed (.di files), these renames wouldn't matter. You can just call the parameter whatever you want.

I am unsure how it would effect the arguments passing since I am not defining that (should be left to a compiler writer to decide that, either here or during implementation).

There is an alternative to this proposal which I prefer and that is to allow implicit construction of structs (with constructor defined to support passed in type). That would handle both deprecated names and types more uniformly but that would require another DIP.

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
>
> All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on September 24, or when I make a post declaring it complete.
>
> At the end of Round 2, if further review is deemed necessary, the DIP will be scheduled for another round of Community Review. Otherwise, it will be queued for the Final Review and Formal Assessment.
>
> Anyone intending to post feedback in this thread is expected to be familiar with the reviewer guidelines:
>
> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>
> *Please stay on topic!*
>
> Thanks in advance to all who participate.

Issues with the "@named" attribute:
1.This is opt-in rather then opt-out, which may causes users to beg the library maintainers to update their libraries to support name attribute.
2. Way too much verbiage for declaring functions with named arguments.
3.I still think the code breakage caused by named arguments is still overblown, I never encounter anyone in the C# who complains about code breakage regarding named arguments.

Most importantly, there should be a alternative solution section detailing Walter suggestion regarding named arguments. It be a total waste to not mention his solution given that it has shown support from other people.

On 11/09/2019 2:01 AM, 12345swordy wrote:
> Issues with the "@named" attribute:
> 1.This is opt-in rather then opt-out, which may causes users to beg the library maintainers to update their libraries to support name attribute.

This is intended.
If you want to override the intention of the API author then we need to find another solution. One which I am unsure about how good it would be.

> 2. Way too much verbiage for declaring functions with named arguments.
> 3.I still think the code breakage caused by named arguments is still overblown, I never encounter anyone in the C# who complains about code breakage regarding named arguments.

The design C# has taken, was more restrictive and quite importantly more conservative than both mine and Walter's.

That may have been a key factor in it not breaking peoples code.

D is a much more complex programming language and almost all talk of named arguments is nonrestrictive in nature. So I disagree with the statement that it is overblown, because it may very well be well founded.

> Most importantly, there should be a alternative solution section detailing Walter suggestion regarding named arguments. It be a total waste to not mention his solution given that it has shown support from other people.

Agreed.

However I am unsure how to add it to the DIP as it is technically not prior work (since as far as I know it did not exist before DIP 1020 was created).

But that is a problem for me to solve at another time.

For reference, there is an example in the DIP related to parameter lists length that IMHO invalidates his proposal. But that is not stated hence some work has to be done on it at a later point.

On Tuesday, 10 September 2019 at 14:19:02 UTC, rikki cattermole wrote:
>> 2. Way too much verbiage for declaring functions with named arguments.
>> 3.I still think the code breakage caused by named arguments is still overblown, I never encounter anyone in the C# who complains about code breakage regarding named arguments.
>
> The design C# has taken, was more restrictive and quite importantly more conservative than both mine and Walter's.
>
> That may have been a key factor in it not breaking peoples code.

Having read DIP 1020, Walter's proposal, and the C# article, the only difference I can find (leaving aside the parts about templates) is that C# is more restrictive about how named arguments may be reordered. I fail to see how this difference could possibly have any impact on the potential for code breakage, since if a parameter name is changed, code will break regardless of what order the arguments are passed in.

If there's some other difference I'm missing that puts DIP 1020 and Walter's proposal at greater risk of breaking code than C#'s named arguments, I'd appreciate if you could point it out explicitly, since I am probably not the only one to have overlooked it.

On 11/09/2019 2:52 AM, Paul Backus wrote:
> On Tuesday, 10 September 2019 at 14:19:02 UTC, rikki cattermole wrote:
>>> 2. Way too much verbiage for declaring functions with named arguments.
>>> 3.I still think the code breakage caused by named arguments is still overblown, I never encounter anyone in the C# who complains about code breakage regarding named arguments.
>>
>> The design C# has taken, was more restrictive and quite importantly more conservative than both mine and Walter's.
>>
>> That may have been a key factor in it not breaking peoples code.
> 
> Having read DIP 1020, Walter's proposal, and the C# article, the only difference I can find (leaving aside the parts about templates) is that C# is more restrictive about how named arguments may be reordered. I fail to see how this difference could possibly have any impact on the potential for code breakage, since if a parameter name is changed, code will break regardless of what order the arguments are passed in.
> 
> If there's some other difference I'm missing that puts DIP 1020 and Walter's proposal at greater risk of breaking code than C#'s named arguments, I'd appreciate if you could point it out explicitly, since I am probably not the only one to have overlooked it.

"No breaking changes are expected except in the case that any codebase declares an existing UDA called named."

I do not expect code breakage to occur in either case.
But I am concerned about the possibility and would prefer to design a little defensively (a few things like is expression handling for templates could break code if it was designed in a different way in DIP 1020).