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

[Manu]

On Mon, Feb 10, 2020 at 1:30 PM 12345swordy via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> 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.

It's a huge problem today when a bad choice of function name is
calcified; we'll be multiplying the probability of making bad naming
choices by 2-3x.
We can correct a bad function name by renaming it and producing a
deprecated alias for the old name. We have no such way to correct a
change in parameter name; we can't use alias because the parameter
names are not part of the signature.

Don't ignore the material issue I've shown that demands one of the 2
responses I suggested.
If you push for acceptable of this DIP, then I think you must have a
response to my primary issue.