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

[FeepingCreature]

On Sunday, 9 February 2020 at 21:05:43 UTC, Jon Degenhardt wrote:
> 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.
>

I feel like this increase in surface area is actually 
straightforwardly a good thing. Even if the parameter is not used 
as a named parameter, we are seeing a shift in the meaning of the 
parameter as understood by the caller. With the DIP, this change 
in meaning will necessarily lead to a reevaluation of the 
callsite and clarification of whether you meant interiorHeight or 
exteriorHeight. With the current state of affairs, absent a 
change in type, there is absolutely no indication to the caller 
that their call has become ambiguous.

Again, the thing that is happening here is a drift in meaning, 
which is *already* a breaking change of the API. The language has 
simply previously allowed developers to obfuscate and ignore this 
fact. Inasmuch as this DIP makes this more difficult, it's a 
benefit, not a drawback.