On Sunday, 31 March 2019 at 13:11:48 UTC, kinke wrote:
>> void func(int a, int b, <bool o>);
>
> I find the syntax terrible. IMO, any extra syntax in the signature isn't acceptable; it should be call-sites-specific only, i.e., C#-style.

AFAIK, languages don't have dedicated named parameters.

On Sunday, 31 March 2019 at 15:53:53 UTC, Andre Pany wrote:
> I still have the opinion we should go for in place struct initialization first.

Or tuples.

As the author of this DIP, I have created a list of actionable items I expect to include in the next iteration of the DIP.

If I have missed something you wish to be included please reply to this post.

In the next few days I expect to write a (short) set of responses so that we can discuss it further. My responses tonight will be directed at non-reoccurring items between the posts.

- Angle brackets, may be hard to find given relationship with templates
  Potential solutions include ``@named``
- External access of template parameters externally needs justification
- Interaction with eponymous templates, invalid
- "Future proposals" sections should probably have a full rewrite to indicate its for recognizing desirable semantics that are out of scope.
- Not in competition with in place struct initialization, different purposes
- More headings (break down behavior)
- Reorder of arguments does not change at symbol site, only at the argument side
- Overload resolution code is flawed with illegal code
- Compare and contrast example code
- Logging case demonstrates that for functions unnamed should be the default API wise
- Duplicate naming is bad, flagging of a parameter as named is better

On Monday, 1 April 2019 at 11:39:50 UTC, rikki cattermole wrote:
> As the author of this DIP, I have created a list of actionable items I expect to include in the next iteration of the DIP.
>
> If I have missed something you wish to be included please reply to this post.
>
> In the next few days I expect to write a (short) set of responses so that we can discuss it further. My responses tonight will be directed at non-reoccurring items between the posts.

Thanks for doing this!

Repeating myself:

>Section "Use Cases" needs more explanation: I don't see how the ranges example revokes the need for ElementType, perhaps a
> "before and after" would be useful here

On 02/04/2019 12:50 AM, Nicholas Wilson wrote:
> On Monday, 1 April 2019 at 11:39:50 UTC, rikki cattermole wrote:
>> As the author of this DIP, I have created a list of actionable items I expect to include in the next iteration of the DIP.
>>
>> If I have missed something you wish to be included please reply to this post.
>>
>> In the next few days I expect to write a (short) set of responses so that we can discuss it further. My responses tonight will be directed at non-reoccurring items between the posts.
> 
> Thanks for doing this!
> 
> Repeating myself:
> 
>> Section "Use Cases" needs more explanation: I don't see how the ranges example revokes the need for ElementType, perhaps a
>> "before and after" would be useful here

Its in there :)

- Compare and contrast example code

On 01/04/2019 11:22 AM, Bastiaan Veelo wrote:

> 1) Any DIP on named arguments nowadays should have references to all prior suggestions and ideas, summarize them and categorize them and clarify why this one is better.

That is a major rabbit hole. I will accept a write up from somebody else, but I do not feel like its a good idea to go down it.

> 3) What is the value of the following?
> 
>  > The function call `func(1, 2, o:true)` is the same as `func(1, o:true, 2)` or `func(o:true, 1, 2)`.

As far as the assembly is concerned, yes.

> So is this equivalent at the definition site as well: `void func(int a, int b, <bool o>);`, `void func(int a, <bool o>, int b);` and `void func(<bool o>, int a, int b);`? Being able to reorder arguments somewhat but not any way you like is confusing.

What matters is the relative ordering between the arguments. If the arguments are forced as per the declaration you lose the ability to express the call as the user sees fit. But if you go too loose you run into code smells and abuse.

This is a lose-lose situation. Some people hate full reordering, some hate no reordering. There is no way to win. With partial reordering perhaps we can have a compromise instead.

> 4) The section on overload resolution is flawed because it contains illegal code:
> 
>  > `void bar(int a, string b = "", int c) {}`

Oof you are so correct.
It should be:

---
void foo(int a, <int c = 0>) {}
void foo(int a, string b = "", <int c = 0>) {}

void bar(int a) {}
void bar(int a, string b = "") {}
---

Does that make more sense now?
(I'll update the DIP with the fix after review)

On Sunday, 31 March 2019 at 12:33:56 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1020, "Named Parameters":

While I generally do not like the idea of named parameters for function calls, I will limit my feedback here to one part of the proposal:

> Arguments matching named parameters must be named arguments, i.e. they must use the name:value syntax. Named arguments must be passed to a function in the same order as the named parameters with which they match appear in the parameter list, but may be passed in any order relative to unnamed arguments. Given the prototype:
>
> void func(int a, int b, <bool o>);
>
> The function call func(1, 2, o:true) is the same as func(1, o:true, 2) or func(o:true, 1, 2).

It is unclear what we would gain from allowing this, and at the same time, it would make it extremely difficult for new users to the language to read code. Reordering unnamed parameters is a recipe for disaster. In some cases, the second argument is x, in some cases it is y, and in yet other cases, it is z. Was there are mistake when writing this:

> Named arguments must be passed to a function in the same order as the named parameters with which they match appear in the parameter list, but may be passed in any order relative to unnamed arguments.

It makes sense to allow named arguments to appear out of order, but unnamed parameters should always have to appear in the same order as they are declared.

It would really help to have an extensive set of examples demonstrating large benefits to implementation of this proposal. It is not a good idea to assume that everyone is familiar with all the details of named arguments, the various arguments for and against, or the alternatives that achieve the same thing. Ideally there should be something that named arguments provide that cannot reasonably be accomplished any other way.

On 02/04/2019 2:06 AM, bachmeier wrote:
> On Sunday, 31 March 2019 at 12:33:56 UTC, Mike Parker wrote:
>> This is the feedback thread for the first round of Community Review for DIP 1020, "Named Parameters":
> 
> While I generally do not like the idea of named parameters for function calls, I will limit my feedback here to one part of the proposal:
> 
>> Arguments matching named parameters must be named arguments, i.e. they must use the name:value syntax. Named arguments must be passed to a function in the same order as the named parameters with which they match appear in the parameter list, but may be passed in any order relative to unnamed arguments. Given the prototype:
>>
>> void func(int a, int b, <bool o>);
>>
>> The function call func(1, 2, o:true) is the same as func(1, o:true, 2) or func(o:true, 1, 2).
> 
> It is unclear what we would gain from allowing this, and at the same time, it would make it extremely difficult for new users to the language to read code. Reordering unnamed parameters is a recipe for disaster. In some cases, the second argument is x, in some cases it is y, and in yet other cases, it is z. Was there are mistake when writing this:
> 
>> Named arguments must be passed to a function in the same order as the named parameters with which they match appear in the parameter list, but may be passed in any order relative to unnamed arguments.
> 
> It makes sense to allow named arguments to appear out of order, but unnamed parameters should always have to appear in the same order as they are declared.

You misunderstood :)

Unnamed arguments must remain in the same order they are declared in.

Named arguments must remain in the same order they are declared in, but they may be inserted in between unnamed arguments giving a partial reordering.

I.e.

void func(int a, <int b>, int c, <int d>) {}

Valid:

func(1, b: 2, d: 3, 4);

Invalid:

func(1, d: 2, c: 3, 4);

Basically, if you split named and unnamed in the above example you would get two sets of parameter lists:

int a, int c
<int b>, <int d>

As long as each parameter list stays in that order, it should be legal to be called/initialized.

Does that answer your question/concerns?

On 4/1/19 6:14 AM, Kagamin wrote:
> On Sunday, 31 March 2019 at 13:11:48 UTC, kinke wrote:
>>> void func(int a, int b, <bool o>);
>>
>> I find the syntax terrible. IMO, any extra syntax in the signature isn't acceptable; it should be call-sites-specific only, i.e., C#-style.
> 
> AFAIK, languages don't have dedicated named parameters.

Scheme [1] and Common Lisp [2] both have dedicated named parameters. It's uncommon, but not completely unheard-of.

[1] https://srfi.schemers.org/srfi-89/srfi-89.html
[2]
http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/sec_3-4-1-4.html

On Sunday, 31 March 2019 at 12:33:56 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1020, "Named Parameters":
>
> https://github.com/dlang/DIPs/blob/39dbbbe5e4618abd4c4b41eb0edd16547858ddf5/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 April 14, or when I make a post declaring it complete.
>
> 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 by the language maintainers.
>
> Please familiarize yourself with the documentation for the Community Review before participating.
>
> https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#community-review
>
> Thanks in advance to all who participate.

> Contrary to the implementation of this feature in other languages, this DIP does not allow arguments to be reordered. The primary aim of this proposal is to aid in readability and the implementation of tooling.

To me, this removes the main reason for wanting this feature in the first place.

> To delineate a named parameter, the parameter declaration is wrapped in angle brackets such that bool o is a standard, unnamed parameter and <bool o> is a named parameter.

There are known reasons why using angle brackets complicates lexing (cough! C++! cough!), so the syntax choice is odd. Is there a particular reason why the usage suggested here avoids the issues?