DIP 1030--Named Arguments--Community Review Round 1 Discussion

[Jon Degenhardt]

On Sunday, 9 February 2020 at 18:32:45 UTC, Steven Schveighoffer 
wrote:
> On 2/8/20 11:10 PM, Jon Degenhardt wrote:
>> For Phobos this would be my expectation as well. I'm 
>> admittedly thinking of project environments with meaningful 
>> size teams more than the standard library of a major 
>> programming language. Environments where there is a fair bit 
>> of code in earlier stages of development and subject to more 
>> evolution.
>
> I think the evolution goes like this:
>
> void foo(int tmpName);
>
> ...
>
> // all callers:
>
> foo(5); // didn't use named parameters because I have no idea 
> what "tmpName" means
>
> now, we evolve foo:
>
> void foo(int milliseconds);
>
> Now, all calls still work because nobody used the bad name as 
> "documentation". New calls now use the name sometimes because 
> it's helpful. My point is simply that the name itself is going 
> to not require, but probably result in, people using or not 
> using the name. Bad names naturally aren't going to get name 
> usage, because they suck and aren't helpful. Good names are.
>
> I understand though, there are possible bikeshed problems here. 
> For example, someone who implements foo might be tired of 
> typing out "milliseconds" and change the parameter name to 
> "ms". Now that person has to worry about what happens for 
> callers. So instead he has to leave milliseconds in the name, 
> and create a temporary ms in his function. At that point, you 
> have to weigh how important it is to change that parameter name 
> against the breakage that might occur. How much does it cost to 
> repaint the shed? Might not be worth it.

Yes, this is representative of what I had in mind. Another is 
changes in the ambiguity of a name.

As an example, assume 'height' is an important element of a 
number of calculations in a system. Early on there is no 
ambiguity about what 'height' means. The word 'height' gets used 
in the names of functions, parameters, variables, etc. Then use 
cases arise where it is important to distinguish interior and 
exterior heights, so names like 'interiorHeight' and 
'exteriorHeight' are preferable.

Over time the name 'height' by itself becomes more and more 
ambiguous. Any place the name 'height' is exposed in a manner 
that other code becomes dependent on the name is a source of 
technical debt.

Often this form of technical debt just happens. It's hard to 
predict these changes. But developers often do spend time 
thinking about forward compatibility of names that are part of a 
public API contract. This DIP will increase this surface area.

As I said, I don't think this is a deal breaker for the DIP. I 
think it is a positive change even with this downside. My only 
recommendation is to consider whether there are mechanisms that 
can help reduce this form technical debt, without requiring 
material additional developer time when initially writing code.

My thought was to allow explicit expression by the developer of 
whether a function was intended for named argument invocation 
(several possibilities). But there may be other approaches to 
achieving the same goal. For example, considering what Swift does:

> Note that Swift (which has parameter names as part of the 
> function name) has a mechanism to deal with this.
>
> [... details excluded... ]
>
> Not sure this could be doable in D. But for a main language 
> that started out with significant naming of parameters 
> (inheriting this from objective-C), it's a good place to look 
> for inspiration here.

This is very nice callout. Even if it cannot be done in D just 
putting it consideration set is worthwhile.

Also, several people have pointed out that aliasing parameter 
names within functions can help with these cases. I agree. It 
doesn't completely address the issue, but it is helpful, and a 
tool I hadn't thought of.

--Jon