DIP 1020--Named Parameters--Community Review Round 1

[Olivier FAURE]

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)