www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP 1030--Named Arguments--Community Review Round 1 Feedback

reply Mike Parker <aldacron gmail.com> writes:
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.
Feb 05 2020
next sibling parent reply Vijay Nayar <madric gmail.com> writes:
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"?
Feb 06 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Feb 06 2020
prev sibling next sibling parent reply Basile B. <b2.temp gmx.com> writes:
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.
Feb 06 2020
next sibling parent Basile B. <b2.temp gmx.com> writes:
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.
Feb 06 2020
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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".
Feb 06 2020
prev sibling next sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
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?
Feb 06 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/6/2020 2:59 PM, Jonathan Marler wrote:

 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?


Please show a specific example, as your description isn't enough.
Feb 09 2020
parent Jonathan Marler <johnnymarler gmail.com> writes:
On Sunday, 9 February 2020 at 21:02:57 UTC, Walter Bright wrote:

 On 2/6/2020 2:59 PM, Jonathan Marler wrote:

 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?


 Please show a specific example, as your description isn't 
 enough.


Here's the example I was referring to:

void snoopy(T t, int i, S s);     // A
void snoopy(S s, int i = 0, T t); // B

...
snoopy(s:s, t:t, i:i); // error, ambiguous
...

I believe this one was indirectly answered here: 
https://forum.dlang.org/post/xeujdoaxungjnbcsvbnf forum.dlang.org

According to the responders there, locally defined functions take 
precedence over externally defined ones.  So the answer seems to 
be no, it will NOT be treated as ambiguous if one of the overload 
definitions is moved to another module.  It seems the current 
overload rules already answer this question for us.
Feb 09 2020
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06.02.20 07:09, Mike Parker wrote:

 ...
 
 You can find DIP 1030 here:
 
 https://github.com/dlang/DIPs/blob/44b0d4ec0da6a2e797ede748fb1e81cd6db1
371/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.
Feb 06 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
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)

?
Feb 07 2020
prev sibling next sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
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
Feb 07 2020
prev sibling next sibling parent reply Arine <arine123445128843 gmail.com> writes:
In the D spec it's stated arguments are evaluated from left to 
right. I know DMD doesn't follow the spec (but LDC2 does). It 
needs to be outlined how arguments are evaluated. What makes 
sense at the call site, or based on the function order. As 
arguments can be passed out of order now.

     __gshared int i = 0;
     void foo(int a = ++i, int b = ++i, int c = ++i, int d = ++i, 
int e = ++i) {
     	writeln(a, " ", b, " ", c, " ", d, " ", e);
     }


     foo(d: ++i, b: ++i); // what does this print?

How does this work with forward declaring? If the same overload 
of function is forward declared multiple times? If it is forward 
declared in the same place as a function? What about for 
interface files .di?

     void foo(int b) { }
     void foo(int a);

     void bar(int d); // declared elsewhere

     foo(a: 10); // ok or no?

     bar(d: 10); // ok?

Otherwise this seems ok.
Feb 08 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/8/2020 9:09 PM, Arine wrote:

 In the D spec it's stated arguments are evaluated from left to right. I know
DMD 
 doesn't follow the spec (but LDC2 does). It needs to be outlined how arguments 
 are evaluated. What makes sense at the call site, or based on the function 
 order. As arguments can be passed out of order now.
 
      __gshared int i = 0;
      void foo(int a = ++i, int b = ++i, int c = ++i, int d = ++i, int e =
++i) {
          writeln(a, " ", b, " ", c, " ", d, " ", e);
      }
 
 
      foo(d: ++i, b: ++i); // what does this print?


It says in the DIP that arguments are evaluated left to right as presented.



 How does this work with forward declaring?


D doesn't have forward declarations.
Feb 09 2020
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On Wed, Feb 5, 2020 at 10:10 PM Mike Parker via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 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.


Named arguments breaks this very important pattern:

auto wrapper(alias origFun)(Parameters!origFun args)
{
  // special sauce
  return origFun(args);
}

Calling with named arguments can not apply to `wrapper` as it does to `origFun`.
Any library that makes use of any such wrapper may not work in
conjunction with named arguments.

As an exercise to the reader; show an implementation of `wrapper`
which preserves argument names and default args... (hint: it's much
more complicated than you think)
Feb 10 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/10/2020 1:02 PM, Manu wrote:

 Named arguments breaks this very important pattern:


Named arguments will not match to ... parameters, so it won't break existing 
code, it just won't compile if you write new code that tries that.
Feb 10 2020
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On Wed, Feb 5, 2020 at 10:10 PM Mike Parker via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 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.


It should be noted that with this DIP, function parameter names become
part of the API, and any change to parameter names (ie, improve
clarity) becomes a breaking change.
There's a fairly high gravity associated with this.
Feb 10 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/10/2020 1:05 PM, Manu wrote:

 It should be noted that with this DIP, function parameter names become
 part of the API, and any change to parameter names (ie, improve
 clarity) becomes a breaking change.
 There's a fairly high gravity associated with this.


Since nobody has missed this, it's pretty clear from the DIP as it is. It's 
kinda obvious that if you call `foo(x:3)` and there is no `x`, it won't compile.


Also, please don't quote the entirety of the message you're replying to.
Feb 10 2020
prev sibling next sibling parent aliak <something something.com> writes:
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".

 [...]


This was brought up in the discussion thread. But a consequence 
of this DIP is that parameter names in the standard library get 
set in stone. So maybe the DIP should mention that? Either as 
acceptable or provide a way to mitigate the issue?
Feb 10 2020
prev sibling parent Atila Neves <atila.neves gmail.com> writes:
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".

 [...]



I think it would be important to consider not always enabling 
named arguments, either by opting in or out of the new feature. 
It could adequately address concerns about parameter names being 
part of the API. For example, I don't think it'd be crazy to 
limit this to only parameters with default arguments.

In Python one can tell the language that certain parameters are 
positional-only:

https://www.python.org/dev/peps/pep-0570/
Feb 17 2020