DIP 1019, "Named Arguments Lite", is now ready for Final Review. This is the last chance for community feedback before the DIP is handed off to Walter and Átila for the 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

The current revision of the DIP for this review is located here:

https://github.com/dlang/DIPs/blob/3bc3469a841b87517a610f696689c8771e74d9e5/DIPs/DIP1019.md

In it you'll find a link to and summary of the previous review rounds. This round of review will continue until 11:59 pm ET on September 6 unless I call it off before then.

Thanks in advance for your participation.

On Friday, 23 August 2019 at 10:54:11 UTC, Mike Parker wrote:
> DIP 1019, "Named Arguments Lite", is now ready for Final Review. This is the last chance for community feedback before the DIP is handed off to Walter and Átila for the 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
>
> The current revision of the DIP for this review is located here:
>
> https://github.com/dlang/DIPs/blob/3bc3469a841b87517a610f696689c8771e74d9e5/DIPs/DIP1019.md
>
> In it you'll find a link to and summary of the previous review rounds. This round of review will continue until 11:59 pm ET on September 6 unless I call it off before then.
>
> Thanks in advance for your participation.

I oppose the empty name feature...

"Parameter name omission
If a function is defined with some of its parameter names omitted, arguments to those parameters can be labeled with an empty name."

I don't see how it could be reasonably implemented, nor what problem it solves.

Consider:
void fun(int, int);
fun(:1, :2); // ???

On Friday, 23 August 2019 at 10:54:11 UTC, Mike Parker wrote:
> Thanks in advance for your participation.

I like how this DIP evolved. The first version looked very unattractive, but it's shaping up to be an elegant proposal. My points for this version:

> In addition, this proposal has the added benefit of protecting against silent breakage in cases when a function's parameters are repurposed and renamed. For example:

Even with named arguments, I wouldn't dare to change the parameter meaning without changing the type. If someone doesn't use named parameters he gets silent breakage anyways. I don't think this is a strong argument in favor of named arguments.

The Prior Work section shows some examples of named parameters in other languages, but it doesn't tell why you chose these languages / why these languages chose their design.

I like the solution to parameter name lock-in, it uses existing languages features for an elegant solution.
> A survey of name changes in popular libraries done by the authors of a similar proposal introducing named arguments to C++ suggests this kind of breakage should be rare.
Can you add a reference to this?

What is the rationale behind variadic functions `args[0]: "string"` or paramater name omission `fun(:10)`?

The grammar changes propose an addition to `ArgumentList`. This production rule is used in other places than function calls though, so this is allowed by the new grammar:
```
mixin(name: "x = 3;");
```

Remove the sections about variadic functions and unnamed parameters.

On Friday, 23 August 2019 at 10:54:11 UTC, Mike Parker wrote:
> DIP 1019, "Named Arguments Lite", is now ready for Final Review. This is the last chance for community feedback before the DIP is handed off to Walter and Átila for the Formal Assessment.
>
> Anyone intending to post feedback in this thread is expected to be familiar with the reviewer guidelines:
>
> The current revision of the DIP for this review is located here:
>
> https://github.com/dlang/DIPs/blob/3bc3469a841b87517a610f696689c8771e74d9e5/DIPs/DIP1019.md
>

now you have to come up with beautiful names for the parameters.
cnt and fmt are illegal.
although this is a headache, but the language will become more beautiful.

On Friday, 23 August 2019 at 12:04:39 UTC, Kagamin wrote:
> Remove the sections about variadic functions and unnamed parameters.

+1

On Friday, 23 August 2019 at 10:54:11 UTC, Mike Parker wrote:

> The current revision of the DIP for this review is located here:
>
> https://github.com/dlang/DIPs/blob/3bc3469a841b87517a610f696689c8771e74d9e5/DIPs/DIP1019.md
>

====
"Named arguments proposed by this DIP have no effect on the ordering of arguments in function calls."

"Named arguments proposed by this DIP do not allow default parameters to be skipped."

"Variadic arguments can be labeled with the name of the variadic parameter and a subscript."

For each of those statements quoted above, I think it would help the DIP to present an example with code and potential compiler output.


====
"If a function is defined with some of its parameter names omitted, arguments to those parameters can be labeled with an empty name."

---
void fun(int);

fun(:10);
---

That seems weird to me.  Why even allow the ":10" syntax?  I recommend adding some justification to the DIP.

Mike

On Friday, 23 August 2019 at 11:24:25 UTC, Daniel N wrote:
> I oppose the empty name feature...

I'm wondering... this DIP say "Final Review" and in this topic I see people complaining about some features like it was added recently, and if this is the case than this DIP process is broken.

"Final" would be like an adjust here and there but for what I see that's not the case here.

Am I missing something?

Max.

On Friday, 23 August 2019 at 13:23:22 UTC, Maximillian wrote:
> On Friday, 23 August 2019 at 11:24:25 UTC, Daniel N wrote:
>> I oppose the empty name feature...
>
> I'm wondering... this DIP say "Final Review" and in this topic I see people complaining about some features like it was added recently, and if this is the case than this DIP process is broken.
>
> "Final" would be like an adjust here and there but for what I see that's not the case here.
>
> Am I missing something?
>
> Max.

The feature was present in the previous revision and the DIP author decided not to remove it.

If you wish to discuss the DIP process further, please start a new thread. I will remind everyone to please keep comments in this thread focused on the DIP itself, as outlined in the document I linked in the first post:

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

I will be deleting any further off topic posts and pasting them into a separate thread.

Thanks!

On 8/23/19 6:54 AM, Mike Parker wrote:
> DIP 1019, "Named Arguments Lite", is now ready for Final Review. This is the last chance for community feedback before the DIP is handed off to Walter and Átila for the 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
> 
> The current revision of the DIP for this review is located here:
> 
> https://github.com/dlang/DIPs/blob/3bc3469a841b87517a610f696689c8771e74d9e5/DIPs/DIP1019.md 
> 
> 
> In it you'll find a link to and summary of the previous review rounds. This round of review will continue until 11:59 pm ET on September 6 unless I call it off before then.
> 
> Thanks in advance for your participation.

The DIP is well researched and clearly written. Kudos.

Sadly I oppose it on the following grounds:

"Named arguments proposed by this DIP have no effect on the ordering of arguments in function calls."

"Named arguments proposed by this DIP do not allow default parameters to be skipped."

These two limitations are as useful and help each other as much as a nausea and a cough.

Large parameter lists of which most have reasonable defaults is a marquee use case of named arguments. A proposal that works itself out of that opportunity cannot and should not be acceptable.

I was unconvinced by the argument that these can be added later. Language design is peculiar in that incrementalism doesn't work well - it must come all at once. There are exceptions and arguments that can be made but there's overwhelming evidence that incremental language design is just not a good way to go about things.