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

[rikki cattermole]

On 11/09/2019 9:10 AM, Walter Bright wrote:
> On 9/10/2019 2:06 AM, Mike Parker wrote:
>> This is the feedback thread for the second round of Community Review 
>> for DIP 1020, "Named Parameters":
>>
>> https://github.com/dlang/DIPs/blob/c723d8f4e3ac2d5bcaf8cdff87e1507f09669ca6/DIPs/DIP1020.md 
> 
> 
> My review is the same as in the first round:
> 
> https://digitalmars.com/d/archives/digitalmars/D/DIP_1020--Named_Parameters--Community_Review_Round_1_325299.html#N325627 
> 
> 
> To which Rikki responded with:
> 
> "That solves function arguments, what is your proposal for templates?"
> 
> https://digitalmars.com/d/archives/digitalmars/D/DIP_1020--Named_Parameters--Community_Review_Round_1_325299.html#N325631 

I stand by my question.
In your proposal there was no mention of template support.

You have since said what your strategy is for templates.

https://digitalmars.com/d/archives/digitalmars/D/DIP_1020--Named_Parameters--Community_Review_Round_1_325299.html#N325650



However I disagree with your rationale.

"Although this supports reordering, the real reason for naming is so one 
can have a function with a longish list of parameters, each with a 
reasonable default, and the user need only supply the arguments that 
matter for his use case. This is much more flexible than the current 
method of putting all the defaults at the end of the parameter list, and 
defaulting one means all the rest get defaulted."

This is a known code smell with a known solution: refactoring.

I will posit that if you have code that has long parameters lists often, 
either you have a lot of technical debt or you are writing code that 
lends itself to introducing technical debt often.

For me at least, when I have long parameter lists, they typically 
involve math and are called in about one or two places at most and quite 
importantly all done within the same module. I do not believe that this 
warrants a language feature in of itself but I can be convinced that 
there are problems that lend itself to long parameter lists that are 
often solved.

Manu has a very interesting story related to this. Involving rewriting a 
code base for the purposes of refactoring of the data abstractions and 
ending up with faster code on platforms that it was expected to be much 
slower on.