DIP 1020--Named Parameters--Community Review Round 2
snarwin at gmail.com
Tue Sep 10 15:37:21 UTC 2019
On Tuesday, 10 September 2019 at 15:07:49 UTC, rikki cattermole
> 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
>>>> 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
>> 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
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.
More information about the Digitalmars-d