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

[12345swordy]

On Monday, 10 February 2020 at 21:17:45 UTC, Manu wrote:
> On Mon, Feb 10, 2020 at 1:05 PM 12345swordy via Digitalmars-d 
> <digitalmars-d at puremagic.com> wrote:
>>
>> On Monday, 10 February 2020 at 20:45:22 UTC, Manu wrote:
>> > On Mon, Feb 10, 2020 at 11:50 AM 12345swordy via 
>> > Digitalmars-d <digitalmars-d at puremagic.com> wrote:
>> >>
>> >> On Monday, 10 February 2020 at 19:38:34 UTC, Manu wrote:
>> >> > On Thu, Feb 6, 2020 at 7:34 PM Jonathan M Davis via 
>> >> > Digitalmars-d <digitalmars-d at puremagic.com> wrote:
>> >> >> [...]
>> >> >
>> >> > I don't have any horse in this race... but I do just want 
>> >> > to
>> >> > echo that
>> >> > I don't understand this feature at all.
>> >> > I don't know what it's for. I've never felt I wanted named
>> >> > arguments
>> >> > personally, and Jonathan's criticism feels very real to 
>> >> > me.
>> >> >
>> >> > [...]
>> >>
>> >> For me personalty, readability\reliability is a huge factor 
>> >> here. Knowing what values should go to where is a big plus 
>> >> for me, when dealing with default arguments. I work with C# 
>> >> code when it comes to web development, and the default 
>> >> parameters prevent me sending values to the wrong parameter.
>> >>
>> >> -Alex
>> >
>> > That feels like a pretty washy justification.
>> Manu, it boils down to mainly experience when it comes to 
>> wanting named arguments. I have argue in favor of them in the 
>> past already in other DIP. I have no interest of repeating 
>> them.
>
> I've seen some arguments, but I haven't understood them 
> personally. I
> don't have a feel for their value, I can't judge that.
> I have described an important material loss associated with 
> this. I'd
> like to see that important issue addressed in the form of "use 
> this
> pattern instead" or, "we accept we are abandoning that important
> pattern, we feel it was less important than this DIP, and we 
> accept
> code that uses that pattern will be broken", which, 
> incidentally, is
> almost all D code I've ever written in a professional 
> capacity... :/
>
> I also have a fear that where making parameter names part of 
> the API;
> renaming parameter == breaking change, this feels bad to me. 
> It's
> resistant to improving API clarity over time.
> In my experience, API clarity is an ongoing maintenance 
> challenge,
> where your poor choice in names is only discovered some time 
> later as
> you have experience with other humans sense of intuition 
> differing
> from your own initial judgement.
> That argument is about equally washy as your core argument, 
> except
> from my personal point of view, I know that my argument here
> absolutely applies to me frequently over decades of experience, 
> while
> I've never wanted names arguments once; so weighing the value
> judgement in that particular compromise seems obvious to me.

Yes, I have encounter the "API breakage" counter argument in 
other threads already. Still not convinced that it is a big issue 
as they make it out to be.