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

[FeepingCreature]

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.