DIP 1020--Named Parameters--Community Review Round 1

[aliak]

On Wednesday, 10 April 2019 at 17:13:04 UTC, Paul Backus wrote:
> On 4/9/19 5:20 PM, aliak wrote:
>> It's worth considering allowing API authors to control how 
>> their APIs ought to be called. I've never completely 
>> understood why reordering is a requirement for some from the 
>> caller's side. It doesn't really add anything in terms of 
>> readability or maintainability in my experience - in-fact it 
>> reduces them because consistency goes out the window. And I'm 
>> not sure how allowing all parameters to be called as named is 
>> going to help in anyway other than making API authors' lives 
>> harder in terms of maintenance costs:
>> 
>
> If you have named arguments, and allow skipping over optional 
> arguments, but *don't* allow reordering, you end up with some 
> really silly-looking errors:
>
> // One of these calls will fail to compile 
> spawnProcess("./do_stuff", stdout: outputFile, stderr: logFile);
>
> // This doesn't, because 'stdout' comes before 'stderr' 
> spawnProcess("./do_stuff", stderr: logFile, stdout: outputFile);
>
> Would you rather (a) have to explain to new D users why the 
> first one
> works and the second one doesn't, or (b) live with parameter 
> reordering
> being allowed?

Most definitely a :) For a few reasons.

1) Semantic meaning: the semantic meaning that is present in the 
order of parameters matters in APIs (not always, but often 
enough). I.e. with algorithms in c++, the call sites would make 
you look twice and go "huh" if _end_ was passed before _begin_. 
So mentally, having to parse all these becomes a harder task:

generate!int(start: 0, end: 10, stride: 2) vs
generate!int(stride: 2, end: 10, start: 0) vs
generate!int(end: 10, stride: 2, start: 0) vs

2) Learnability: Having fixed pos parameters is easier to learn 
because you consistently repeat the same pattern

3) Reduced mental anguish :p - ok I'm being a bit dramatic here 
and I have no data to back this up, but if I saw this:

auto c = color(g=123, b=2, a=3, r=7)

I personally, and I'm pretty sure I'd bet monies that any - or 
most - graphics engineers, would die just a weeeee little bit.

4) Consistency: allowing all the possible permutations of a 
function would just lead to inconsistent call sites. Consistent 
is usually better than inconsistent in any large code base.

5) Searchability: searching is possible - grepping or ctrl+f 
"function(firstName:" has helped me out *many* times. You could 
not rely on this if re-ordering is allowed.

6) What's so complicated about the explanation: "yeah you have to 
specify the arguments in order they're declared"? I've been using 
objective-c and then swift for the past 7 years now, and I 
haven't been confronted with the any kind of negativity 
associated to not being able to reorder arguments.

Also: if named arguments are reorderable and optional, should we 
worry about this scenario - i'm not sure we should but just 
throwing out there as a thought:

// User A writes code
move(y=0, x=1)
// User B comes at some point and decides variable names are good 
enough
move(y, x)

// and the actual function declaration is:
move(int x, int y)

For the record, I could live with either - but I have a 
preference for positional. I don't see the advantage of 
reordering though. Is it just to avoid not having to tell people 
that you need to specify arguments in the order they're declared? 
Is it because it's easier to write out the function call? Are 
there some technical advantages? Is it (much) easier to implement?

Cheers,
- Ali