Discussion Thread: DIP 1030--Named Arguments--Final Review

[Steven Schveighoffer]

On 5/14/20 1:57 AM, Walter Bright wrote:
> On 5/13/2020 7:00 AM, Steven Schveighoffer wrote:
>> As was pointed out in the last review -- if you have structs with 
>> public member fields and you changed those names, the breakage would 
>> be more severe than just a broken initializer call:
>>
>> auto s = S(1, 2, 3);
>>
>> writeln(s.foo); // Error, no member foo, did you mean Foo?
> 
> I don't know about "more severe". It would just give an error that a 
> matching function was not found, and would pretty-print the list of 
> candidate functions.

I guess I should have said "more common". The point is, if you change 
the field names, people will notice first that they can't use the field 
names, not that the initializer call doesn't work.

I personally like named parameters, and I'm good with the struct 
initializer syntax as well. I just don't think that your assertion that 
the lack of complaints about initializer syntax breakage when people 
change field names is somehow proof that it won't be a problem for 
parameter name changes when named parameters are available. They would 
first complain that their usage of the structs has now broken.

At the same time, I'm fine with the result that changing parameter names 
is going to break calling code. Just name your parameters better.

My still only 2 complaints here are that there is a lack of deprecation 
path for parameter name changes, and that you cannot create wrapper 
types that forward the namedness.

> Besides, if you really don't want your users to use the parameter names,
> 
>      int foo(int _dkfjjiufheuehgthu, long _yer_mother_was_a_hamster, 
> double _I_did_not_read_the_documentation);
> 
> and I bet they'll get the message.

I don't think they will. I think you would get at least one bug report 
per week that you should rename these parameters to something more 
intuitive.

-Steve