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

[Manu]

On Mon, Feb 10, 2020 at 1:55 PM jmh530 via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Monday, 10 February 2020 at 21:41:02 UTC, Manu wrote:
> > [snip]
> >
> > 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.
>
> I was leaning towards favoring this DIP, as I frequently use
> named arguments in R and like the flexibility they offer in some
> cases. However, I came across two functions, written in python,
> at work. One takes a parameter and the other takes a slightly
> different parameter name. No good reason why these two do not use
> the same parameter names. They should be the same. However,
> python has named arguments for everything, so changing the names
> would mean that any code that uses the named version breaks. It
> definitely would make people much more conservative about
> changing their functions.

We deprecate and rename things all the time. If this DIP is accepted,
I think it would be the case that we need a working pattern to
deprecate argument names the same as we can with function names today.
We can't use alias, because names are not part of the signature. We
can't use overloads as backwards-compatibility wrappers, because
they're ambiguous calls (again, because names are not pert of the
signature).

Calcification of API will increase. Poor name choices will be cemented in.


On Mon, Feb 10, 2020 at 2:00 PM 12345swordy via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Monday, 10 February 2020 at 21:41:02 UTC, Manu wrote:
> > 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.
>
> Which is a no big deal when the probability is very low to big
> with.

Ummm... you're saying bad API names has a "very low probability"?
Finish this sentence: "There are 2 hard problems in computer science..."

I mean, I'm constantly tweaking API's for intuitive appeal.
Programmers do this _all the time_.

> We literally have two named arguments DIP that are postponed for
> this DIP. The discussion has been made so many times already in
> which your concerns and objections has brought up time and time
> again. Which frankly I don't have time nor the energy to argue in
> favor it again when you can look into those discussions threads
> already.

I've never posted a single comment in a named argument thread. It's
just not a thing I care about.
I commented today because I feel like this DIP has a high probability
of acceptance (because Walter wrote it), and I wanted to understand
what was about to happen.

I'm still mostly ambivalent about this, but I'm concerned you're still
carefully avoiding my key concern; I showed an entire class of code
that will be broken, you need to have a response to that.
Basically everything I've ever written in a professional capacity will
cease working if clients can call with named arguments.

> There is no apocalypse scenario in C# community, when it comes to
> named arguments.

They didn't have a decade of existing and important code that will break.
I think accepting this DIP must be coupled with a recommended pattern
to address the code I described, because it will be broken, and must
be migrated.


On Mon, Feb 10, 2020 at 2:10 PM Adam D. Ruppe via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Monday, 10 February 2020 at 20:50:40 UTC, Manu wrote:
> > Not being able to easily produce call shims or wrappers is a
> > huge loss without some sort of solution analogous to existing
> > reflection tools.
>
> This does not occur.

I don't understand... ?