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

[Manu]

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.