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

[Steven Schveighoffer]

On 2/8/20 8:47 PM, Jon Degenhardt wrote:
> On Sunday, 9 February 2020 at 01:07:03 UTC, Adam D. Ruppe wrote:
>> On Sunday, 9 February 2020 at 00:56:15 UTC, Jon Degenhardt wrote:
>>> (Specifically, that a parameter name cannot be changed without risk 
>>> of breaking existing callers.)
>>
>> Does it change your view at all that parameter names are *already 
>> public* per both spec and reality and have been for a long, long time? 
>> (my web.d framework used their availability as early as 2012ish)
>>
>> See item #6 here: https://dlang.org/spec/expression.html#IsExpression
>>
>> "the parameter sequence of a function, delegate, or function pointer. 
>> This includes the parameter types, names, and default values."
>>
>> And, of course, documentation though that isn't strictly part of the 
>> compiler breakage.
> 
> Probably not, but let me give some thoughts and ask a clarifying question.
> 
> Main thing - As a pragmatic matter, I'd expect it to be much more likely 
> that named argument invocation would be a source of breakage than usage 
> arising from introspection.
> 
> Related - There is significant difference between parameter names being 
> public and having the names be sources of backward compatibility in 
> function calls.
> 

If you name your parameters something unintuitive, like "a". Likely 
nobody is going to use them via named parameters.

For example, if you have;

Date makeDate(int year, int month, int day)

What would be the reason to change these? Likely you already picked 
those names.

But if you named them:

Date makeDate(int a, int b, int c)

Now, changing it to the more appropriate names as above would be 
technically a "breaking change". But who cares? Nobody is writing 
makeDate(b: 1, c: 2, a: 3), and if they are, they deserve broken code IMO.

I don't think there's going to be a lot of problems here. Take a look at 
the history of phobos and see if you can find places where someone 
changed an appropriate parameter name to another appropriate name. 
Chances are it's close to never. And even if it was changed, is the 
change something that would have to be made? Was the original parameter 
name so bad that it needed changing in light of the code breakage that 
would now take place?

The one annoying downside is that there is no possibly way to deprecate 
this. You can't have:

@deprecated("use better names please") Date makeDate(int a, int b, int c)
Date makeDate(int year, int month, int day)

This is one huge departure from current mechanisms.

-Steve