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

[aliak]

On Wednesday, 27 February 2019 at 02:17:30 UTC, Jonathan M Davis 
wrote:

> Personally, I hope that we never have any form of named 
> arguments in D (beyond whatever folks do with libraries, though 
> I hope never have to deal with code that uses such libraries). 
> But ultimately, that's going to be up to Walter and Andrei...

Curious. How come?

Would it not be nicer for contributors to know what "TexPos(1, 
1)" (from your dxml library) does without having to lookup 
TextPos? I actually got it wrong from just reading the source. I 
thought it was pixel positions x, y. But nope.

Another thing is that almost every time I see std.traits 
anywhere, I NEVER know which argument is what and always have to 
look it up. Multiply this by every programmer who has to code 
review, or maintain code and it's a lot of wasted time that's 
solved with proper use of named arguments.

Some arguments I have heard about against named arguments though:

1) verbosity of call-site - solvable when named arguments are 
optional, should the API designer think so. It's the same as if 
an API designer decides to call a publicly accessible property 
"config" or "configuration". If there's a function that takes one 
argument, it makes little sense for an API writer to force it to 
be named. But as long as that choice is given, the purpose is to 
make the function as natural as possible.

2) Parameter lock in - don't see how that's different than 
function name lock in. Choose a name, use it. It goes through 
code reviews. If you change it, you bump a version number. I 
guess the number of places where the api can break increases 
though. But from a number of years of experience, I have not 
experienced this. Plus, I tend to find that API "superficially" 
used named arguments

Example from std:

topN(r, 3)
topNCopy(r1, r2)
topNIndex(r1, i1)

These are the same function with different named arguments:

topN(r, 3)
topN(r, copy: r2)
topN(r, index: r2)

But since you don't have named arguments you put the name part of 
the arguments in the function name.

3) Needing to think about parameter names. You don't if they're 
optional. As the API designer. You need to think about the public 
interface of your function name anyway. And, if you're making 
public APIs, you're making docs (I hope). So you're already doing 
this. You would have to think if the API required named arguments 
or not though.

4) ??

Cheers,
- Ali