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

[Paul Backus]

On Tuesday, 10 September 2019 at 15:07:49 UTC, rikki cattermole 
wrote:
> On 11/09/2019 2:52 AM, Paul Backus wrote:
>> On Tuesday, 10 September 2019 at 14:19:02 UTC, rikki 
>> cattermole wrote:
>>>> 2. Way too much verbiage for declaring functions with named 
>>>> arguments.
>>>> 3.I still think the code breakage caused by named arguments 
>>>> is still overblown, I never encounter anyone in the C# who 
>>>> complains about code breakage regarding named arguments.
>>>
>>> The design C# has taken, was more restrictive and quite 
>>> importantly more conservative than both mine and Walter's.
>>>
>>> That may have been a key factor in it not breaking peoples 
>>> code.
>> 
>> Having read DIP 1020, Walter's proposal, and the C# article, 
>> the only difference I can find (leaving aside the parts about 
>> templates) is that C# is more restrictive about how named 
>> arguments may be reordered. I fail to see how this difference 
>> could possibly have any impact on the potential for code 
>> breakage, since if a parameter name is changed, code will 
>> break regardless of what order the arguments are passed in.
>> 
>> If there's some other difference I'm missing that puts DIP 
>> 1020 and Walter's proposal at greater risk of breaking code 
>> than C#'s named arguments, I'd appreciate if you could point 
>> it out explicitly, since I am probably not the only one to 
>> have overlooked it.
>
> "No breaking changes are expected except in the case that any 
> codebase declares an existing UDA called named."
>
> I do not expect code breakage to occur in either case.
> But I am concerned about the possibility and would prefer to 
> design a little defensively (a few things like is expression 
> handling for templates could break code if it was designed in a 
> different way in DIP 1020).

I think you've misunderstood what 12345swordy and I are saying. 
The concern is not that DIP 1020 (or any other implementation of 
named arguments) will cause breakage *itself*, but that making 
parameter names part of a function's public interface could lead 
indirectly to *future* code breakage if any of those names are 
changed.

12345swordy's point #3 was that the above concern is, in his 
opinion, overblown, and that therefore we shouldn't bother 
requiring a @named attribute on parameters to address it. 
Personally, I share this opinion; my own experience in Python 
(which handles named arguments similarly to C#) is that 
parameter-name changes are not a problem in practice.