DIP 1030--Named Arguments--Community Review Round 1 Discussion

[Piotrek]

On Friday, 7 February 2020 at 03:33:26 UTC, Jonathan M Davis 
wrote:
[...]
> Well, I'll say again that I don't like the idea of having named 
> arguments in the language, because it makes the parameter names 
> part of the API, resulting in yet more bikeshedding and yet 
> another thing that can't be changed without breaking existing 
> code.

For me, the DIP is on the top of the improvements list. I missed 
it many times. I found the code with named arguments much more 
readable no mater how many arguments are defined for the 
functions (i.e. including those with even 1 argument in some 
cases).

Regarding API design. To some extent the names of arguments are 
already a part of API in any programming language. They form a 
documentation for users which can be referenced in many places.

As for the "breaking change" problem. My opinion is that there 
should be an appropriate deprecation process available for any 
change in the language without an exception. Surly it needs some 
planning and rationale which is costly, making it not 
straightforward and not applicable in some cases. But the 
"braking change" problem shouldn't be an unbreakable barrier for 
improvements which are worth it. Additionally DIPs have trial 
period, don't they?

Piotrek