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.

> 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.

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.

I don't like the angle brackets for the aesthetic reason that it loos like C++ and for the practical reason that there is an asymmetry w.r.t. the way it is declared and the way it is used. I would much prefer

void func(int a, int b, bool:o);
...
func(1, 2, o:true);


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 3/31/2019 9:33 PM, 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 
> 

The following link has a couple of source code formatting errors fixed:

https://github.com/dlang/DIPs/blob/367741ed43d2491f25542b6fda043ad1d81a1461/DIPs/DIP1020.md


And of course, the latest version is always available at:

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1020.md

On 3/31/19 8:33 AM, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1020, "Named Parameters":

Some remarks:

1. The angle-bracket syntax is an odd choice. There's no precedent in D (or, as far as I know, any other language) for angle-brackets indicating that names are significant, so anyone encountering this syntax for the first time is going to have to look it up to know what it means. If they're clever, and speak English well enough to know that "<>" are called "angle brackets", they'll still have to avoid getting sidetracked by the "Template Comparison" [1] page in order to find the page in the language spec that covers named parameters (which hopefully includes the words "angle brackets" itself...).

Ironically, I think this version of named parameters would be a much better fit for an attribute like @named or @keyword than the one in DIP 1019. Not only would such an attribute convey its meaning better to an unfamiliar reader than angle brackets, it would also be much easier to search for.

2. The feature that allows named parameters of templates to be accessed as though they were members of the template requires explicit justification for its inclusion. It is (a) orthogonal to the rest of the proposal, (b) possible to implement in user code, either by hand or as a mixin template, and (c) an unavoidable source of namespace pollution.

The interaction with eponymous templates is also non-obvious. Naively, one might expect the eponymous member and the named-argument members to be siblings, but in the case of (e.g.) `struct Foo<T> {}`, the member for T is actually *inside* the eponymous member.

I'm sure there are good reasons for proposing this feature, but those reasons need to be stated directly in the DIP itself, not left for the reader to infer.

3. The "Future Proposals" section is very weak. Adding ordering restrictions after the fact would be a breaking change, and the hypothetical "API Alias Parameters" feature is difficult to understand and of no obvious use without further elaboration. I would recommend removing this section from the DIP entirely.

[1] https://dlang.org/articles/template-comparison.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.

I still have the opinion we should go for in place struct initialization first. Here we get named parameters implicit without adding a complete new syntax. I also do not like the new syntax <>.
Leveraging what inplace struct initialization syntax gives us, seems a lot more reasonable in my opinion.

Kind regards
Andre

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

I'll be way more harsh than the other posters here, sorry in advance.

Andrei was talking recently about how some contributions didn't have the level of quality required to be useful to a project; and how these contributions could have structural problems so deep, that no amount of incremental changes would fix them.

As far as I can tell, this is one of them. I cannot imagine any version of this DIP being accepted, ever.

- As the others have pointed out, the syntax is terrible. It could work in another language, but it's a very bad fit for D, and it looks too much like C++ templates, which are unrelated to named arguments.

- The DIP doesn't consider alternative syntaxes. Named arguments in particular are a concept that can be executed in any numbers of ways, both at the declaration site and the call site. A strong proposal would need to list these potential ways, and why one of them is stronger than the others. The DIP points out that DIP-1019 exists, but doesn't make any comparison or give any reason to implement DIP-1020 over DIP-1019.

- The rationale is extremely weak. "Other languages do X" and "People said we shouldn't do Y" isn't a valid rationale. A good rationale should detail why people want named arguments, and why other languages include them. The author should do some analysis work, to explain the deeper semantics of named arguments, why they are useful, their drawbacks, and why the current proposal best addresses these semantics while avoiding their drawbacks.

Overall, my subjective feeling is that the DIP is closer to a shower-thought idea, than the result of a comprehensive analysis process. I don't get the feeling the author has spent enough time considering possible alternatives, complexity and maintenance cost, interoperability with existing semantics, etc. In fact, I don't think the author has spent a 10th of the time necessary to properly address these problems.

So I don't think this DIP should make it anywhere past community review.

(sorry)

Thank you Richard for writing the DIP.

I subscribe to Olivier's review and won't repeat those critiques. In addition, I have the following concerns.

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.

2) Different subjects should have different section headings ("Overload resolution", "Variadic parameters", etc).

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)`.

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.

4) The section on overload resolution is flawed because it contains illegal code:

> `void bar(int a, string b = "", int c) {}`

5) Use cases. The "Ranges" case needs to open with what the example looks like without the DIP, and then with the DIP, so that its value becomes apparent. So one of the advantages of this DIP is that fewer types and instantiations are needed? That is fundamental and should be further explained and certainly goes beyond syntax sugar or mere improvement of readability. What is necessary, compiler implementation wise, to support that?
The "Logging" case (grouping of arguments that the user typically would not want to bother with) has nothing to do with named arguments as users won't typically name those arguments.


6) About the aim of the DIP:

> "The primary aim of this proposal is to aid in readability and the implementation of tooling."

I have no idea how this DIP is supposed to aid in the implementation of tooling. There is no further mentioning of tooling at all. What is left is "aid readability" which I agree would be a worthwhile improvement. However, in this DIP, what is gained in readability at the call site is smaller in value than what is lost in readability at the definition site, to a net loss.

The value in readability should be weighed against ordinary comments:

   `func(1, 2, o:true)`

versus

    `func(1, 2, /*o*/ true)`

Note that the comment has the added advantage that it is optional at the call site. This DIP should justify itself against the obvious solution which in my eyes is accepting `o:` in this example as a comment. It would be easy to accept an identifier followed by a colon in a parameter list as a new syntax for a comment. It would work everywhere and be optional. As an extra service, the compiler could check the comment against the function definition and issue a warning in case of a mismatch: "Warning: argument 3 of 'func' is not called 'o', did you mean 'q'?" or the like. Maybe this is worth a DIP?

Bastiaan.

> ... 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.

I don't see any value in the DIP, what do I gain? I can't re-order arguments, which would IMO be THE use-case for named parameters.

Aid in readability by adding more syntax is counter productive. It lowers readability. I can add a comment where apropriate if necessary.

Without a strong use-case and a clear argumentation about the benefits over current options, it is totally unclear why the DIP is necessary.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

On Monday, 1 April 2019 at 06:28:57 UTC, Robert M. Münch wrote:
> Aid in readability by adding more syntax is counter productive. It lowers readability. I can add a comment where apropriate if necessary.
>
> Without a strong use-case and a clear argumentation about the benefits over current options, it is totally unclear why the DIP is necessary.

I don't have an opinion on the relative merits of the DIP, I just want to voice why named arguments are useful - they allow you to *force* semantic coupling between the caller and the callee in a way that comments don't.

As it stands, it is essentially impossible to determine the purpose of a parameter in a function call in many cases. `foo(sum)` tells you basically nothing about what `foo` actually wants the `sum` parameter *for*. If you could demand in code reviews that such cases used named parameters, you would end up with a much more pleasant expression such as `foo(iterationSteps: sum)`; simultaneously, the call to foo would be committed to a particular semantic interpretation of its parameter, such that `foo` could indicate that it had changed its meaning without being **forced,** as it currently is, to either change its type, go through an awkward deprecation/reimplementation cycle, or invite silent breakage on updates.

Named parameters are a clear win for readability and maintainability, imo.