DIP 1019--Named Arguments Lite--Community Review Round 1

[Olivier FAURE]

On Friday, 15 February 2019 at 20:35:14 UTC, Yuxuan Shui wrote:
> I am not saying "we should never break any code". I am 
> deferring that decision to someone else. If someone want to 
> make named parameters opt-out instead of opt-in, they can do so 
> on top of this DIP. I am just not doing that in my proposal.

I think that, at least, you should include more details in the 
DIP text about what kind of breakage the @named attribute would 
prevent, how these breakages would otherwise occur, and what kind 
of situation would lead to them.

I personally think breakages are unlikely:

- The maintainer needs to export functions with argument names.
- The user has to explicitly use DIP-1019 and use named arguments.
- The maintainer has to change the argument names, without being 
aware of DIP-1019 and using your forward declaration workaround 
(and without being made aware of it by subsequent issues).
- Then the user gets an easy-to-fix compile error when they 
update their library.

In these cases, the user can always avoid using named arguments 
if there's a significant risk that named breakage occurs (eg if 
the library was written before DIP-1019).

Keep in mind that library maintainers can always opt out of named 
arguments by exporting prototypes with anonymous arguments:

     int foobar(int, float, string);

All-in-all, it's a trade-off with downsides either way, but I 
think being able to use named argument with any library made at 
any time far outweighs the breakage risks.