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.

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.

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.

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.

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)

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.

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?

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.

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.

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/