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

[Tove]

On Thursday, 14 May 2020 at 19:55:02 UTC, Steven Schveighoffer 
wrote:

> If you use _xyz as a named parameter, and the name changes to 
> _abc, that's your fault.
>
> Just an idea, in the event that we cannot find a good way to 
> have the compiler prevent named parameter usage.
>
> -Steve

Some people love Named Arguments. (They might overuse it)
Some people hate Named Arguments. (They might overlook good 
opportunities to use it)

If someone who hates named arguments creates a library, I don't 
really see the point of hir restricting the freedom of the 
developer that uses said library. The entire risk lies with the 
developer that loves named arguments, it should be upto that 
person to decide if the risk is worth it or not.

That said, as much as I love named arguments, I would never use 
an argument starting with underscore as it's simply too ugly, 
it's a very effektive deterrent, even without a convention... but 
with the added power of the convention the risk of using it would 
be minimal.

It's also possible that the opposite happens of what you all seem 
so afraid of, the library author decides to change the order of 
the arguments to facilitate UFCS but keeps the argument names 
unchanged, which saves the named argument user from breakage! I 
have made this kind of facilitate UFCS refactorings in my own 
codebase more often than changing argument names.

TL;DR
1) I think _ is effective
2) Using a di is also a good solution...
3) .. or having different submodules to keep backwards 
compatibility akin to namespace versioning in recent C++.

We have enough ways to handle this already, I'm totally with 
Walter on this one. Best DIP ever!