This is the feedback thread for the first round of Community Review of DIP 1030, "Named Arguments".

===================================
**THIS IS NOT A DISCUSSION THREAD**

Posts in this thread must adhere to the feedback thread rules outlined in the Reviewer Guidelines (and listed at the bottom of this post).

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

That document also provides guidelines on contributing feedback to a DIP review. Please read it before posting here. If you would like to discuss this DIP, please do so in the discussion thread:

https://forum.dlang.org/post/ngjihdoyluxrikjzcxhk@forum.dlang.org

==================================

You can find DIP 1030 here:

https://github.com/dlang/DIPs/blob/44b0d4ec0da6a2e797ede748fb1e81cd6db10371/DIPs/DIP1030.md

The review period will end at 11:59 PM ET on February 20, or when I make a post declaring it complete. Feedback posted to this thread after that point may be ignored.

At the end of Round 1, 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.

==================================
Posts in this thread that do not adhere to the following rules will be deleted at the DIP author's discretion:

* All posts must be a direct reply to the DIP manager's initial post, with only two exceptions:

    - Any commenter may reply to their own posts to retract feedback contained in the original post

    - The DIP author may (and is encouraged to) reply to any feedback solely to acknowledge the feedback with agreement or disagreement (preferably with supporting reasons in the latter case)

* Feedback must be actionable, i.e., there must be some action the DIP author can choose to take in response to the feedback, such as changing details, adding new information, or even retracting the proposal.

* Feedback related to the merits of the proposal rather than to the contents of the DIP (e.g., "I'm against this DIP.") is allowed in Community Review (not Final Review), but must be backed by supporting arguments (e.g., "I'm against this DIP because..."). The supporting arguments must be reasonable. Obviously frivolous arguments waste everyone's time.

* Feedback should be clear and concise, preferably listed as bullet points (those who take the time to do an in-depth review and provide feedback in the form of answers to the questions in this document will receive much gratitude). Information irrelevant to the DIP or is not provided in service of clarifying the feedback is unwelcome.

On Thursday, 6 February 2020 at 06:09:36 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review of DIP 1030, "Named Arguments".

Regarding the matching rule No. 2 quoted below:

> Matching of NamedArguments to a function's, function pointer's, or delegate's parameters proceeds in lexical order. For each NamedArgument:
>
>  1. If an Identifier is present, it matches the Parameter with the corresponding Identifier. If it does not match any named Parameter, then it is an error.
>  2. If an Identifier is not present, the Parameter matched is the one following the previous matched Parameter, or the first Parameter if none have yet been matched.

If one is using Uniform Function Call Syntax, the first parameter is already filled in with the object to the left of the "." symbol.  Does this create a conflict?  For example:

void doStuff(int a, string b, double c) { ... }

3.doStuff(6.7, b: "ham")

In this example, "6.7" is the first argument, it does not have an Identifier, but it cannot be matched to the first argument, because "3" has already been filled in for that. Or in this proposal, do the arguments matched via UFCS count as a "previous matched parameter"?

On Thursday, 6 February 2020 at 06:09:36 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review of DIP 1030, "Named Arguments".

What are the semantics on functions without named parameters ?
They automaticaly create identifiers IIRC so can we expect this to work

---
void foo(int, float);

foo(__parameter1: 0, __parameter2: 0.0f); ?
---

or would this be illegal ?

Need spec.

On Thursday, 6 February 2020 at 11:29:59 UTC, Basile B. wrote:
> On Thursday, 6 February 2020 at 06:09:36 UTC, Mike Parker wrote:
>> This is the feedback thread for the first round of Community Review of DIP 1030, "Named Arguments".
>
> What are the semantics on functions without named parameters ?
> They automaticaly create identifiers IIRC so can we expect this to work
>
> ---
> void foo(int, float);
>
> foo(__parameter1: 0, __parameter2: 0.0f); ?
> ---
>
> or would this be illegal ?
>
> Need spec.

I'de be in favor of this position: This should not work because the unknown name is specific to the compiler implementation.

On 2/6/2020 3:29 AM, Basile B. wrote:
> What are the semantics on functions without named parameters ?

They don't have names, so any attempt to apply a name to them would be "no match".

On 2/6/2020 2:05 AM, Vijay Nayar wrote:
> In this example, "6.7" is the first argument, it does not have an Identifier, but it cannot be matched to the first argument, because "3" has already been filled in for that. Or in this proposal, do the arguments matched via UFCS count as a "previous matched parameter"?

  3.doStuff(6.7, b: "ham")

is simply an alternative syntax to:

  doStuff(3, 6.7, b: "ham")

I.e. no semantic difference.

On Thursday, 6 February 2020 at 06:09:36 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review of DIP 1030, "Named Arguments".
>
> [...]

How will the compiler handle function lookup if there is an ambiguous match, but the ambiguous function is in another module?  So in your snoopy example, if one of the snoopy overloads was defined in another module, is the compiler still supposed to treat that as ambiguous?

On 06.02.20 07:09, Mike Parker wrote:
> ...
> 
> You can find DIP 1030 here:
> 
> https://github.com/dlang/DIPs/blob/44b0d4ec0da6a2e797ede748fb1e81cd6db10371/DIPs/DIP1030.md 
> 
> ...
This introduces syntax like:

import std.typecons;
alias t=AliasSeq!(c:1, a:2, b:3); // valid according to DIP
void foo(int a,int b,int c){
    writeln(a," ",b," ",c);
}

void main(){
    foo(t);
}

I'd expect this to print "2 3 1".

I think this is important for forwarding applications, so deserves explicit treatment. There should also be a way to access the argument names in a given sequence.

This is also the reason why I think this part of the DIP is probably not ideal: "If there are more NamedArguments than Parameters, the remainder match the trailing ... of variadic parameter lists, and Identifiers are not allowed."

IMHO, any leftover named arguments should be collected into the variadic parameters.

On 2/6/20 1:09 AM, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review of DIP 1030, "Named Arguments".

Some thoughts on the variadic matching:

---
5. If there are more NamedArguments than Parameters, the remainder match the trailing ... of variadic parameter lists, and Identifiers are not allowed.

---

What happens here?

template foo(T...) {}

foo!(T: 1, 2, 3);

I think it should compile and the result should be foo!(1, 2, 3)

Same thing for something like:

void foo(int[] arr...)

foo(arr: 1, 2, 3)

----

Regarding only matching if there are more named arguments than parameters, I think this needs rewording. According to that description, what happens on these calls?

void foo(int a, int b, ...)

foo(b: 1, a: 2, 3, 4, 5)

According to rule 2, the argument 3 should match b. But according to rule 5, it should match the variadic parameters.

Another case:

foo(b:1, 2, 3, a:4, 5, 6)

---

my recommendation is that rule 5 be reworded like:

"If an identifier is not present, and the parameter being selected by rule 2 is the trailing variadic `...`, then the argument is added to the variadic arguments of the function."

And add rule 6:

"If an identifier matches a variadic template parameter name, or a type safe variadic parameter name, then that argument becomes the first element in the variadic match. Any subsequent parameters without identifiers match the trailing `...`. You cannot match a variadic by name more than once."

-Steve

On 2/6/2020 7:49 PM, Timon Gehr wrote:
> 
> import std.typecons;
> alias t=AliasSeq!(c:1, a:2, b:3); // valid according to DIP
> void foo(int a,int b,int c){
>      writeln(a," ",b," ",c);
> }
> 
> void main(){
>      foo(t);
> }
> 
> I'd expect this to print "2 3 1".
> 
> I think this is important for forwarding applications, so deserves explicit treatment. There should also be a way to access the argument names in a given sequence.
> 
> This is also the reason why I think this part of the DIP is probably not ideal: "If there are more NamedArguments than Parameters, the remainder match the trailing ... of variadic parameter lists, and Identifiers are not allowed."
> 
> IMHO, any leftover named arguments should be collected into the variadic parameters.

So,

    void foo(int a, ...);

called with:

    foo(b:1, 2)

should be the equivalent of:

    foo(2, 1)

?