Discussion Thread: DIP 1030--Named Arguments--Final Review

[jmh530]

On Monday, 11 May 2020 at 11:37:07 UTC, Mike Parker wrote:
> [snip]

I think the arguments brought on in the previous review with 
respect to the API remain a concern. The feedback notes this 
issue, but in response the DIP author notes that if a parameter 
is not found then it is an error. Of course, this is the whole 
issue. Someone can change
void foo(int x, int y, int z) {}
to
void foo(int x, int a, int b) {}
and user code that relies on calling foo with keywords for y and 
z will break. I think this also connects with the feedback that 
the feature should be opt-in.

I think the comments in the prior discussion with respect to 
Python's positional-only and keyword-only arguments make sense 
(see [1] for the PEP on this). In particular, the only change I 
would make to this DIP would be to make it so that keyword 
arguments are opt-in, such asmaking the syntax something like
auto functionName(positional_only_parameters, /, 
positional_or_keyword_parameters) {}
While python requires "/" to force positional_only this is 
because "positional_or_keyword_parameters" is the default. Thus, 
I would recommend having / to force 
positional_or_keyword_parameters. So for instance, you could 
still have
void foo(int x, int a, int b) {}
and only have positional arguments and no breakage if names 
change, or you could potentially allow keyword arguments, as in
void foo(int x, /, int a, int b) {}
and call it like
foo(3, 2, 1);
foo(3, 2, b:1);
foo(3, a:2, b:1);
foo(3, b:1, a:2);



[1] https://www.python.org/dev/peps/pep-0570/