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

Manu turkeyman at gmail.com
Mon Feb 10 19:38:34 UTC 2020


On Thu, Feb 6, 2020 at 7:34 PM Jonathan M Davis via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Wednesday, February 5, 2020 11:08:59 PM MST Mike Parker via Digitalmars-d
> wrote:
> > This is the feedback thread for the first round of Community
> > Review for DIP 1030, "Named Arguments":
> >
> > https://github.com/dlang/DIPs/blob/44b0d4ec0da6a2e797ede748fb1e81cd6db1037
> > 1/DIPs/DIP1030.md
> >
> > Here in the discussion thread, you are free to discuss anything
> > and everything related to the DIP. Express your support or
> > opposition, debate alternatives, argue the merits... in other
> > words, business as usual.
> >
> > However, if you have any specific feedback for how to improve the
> > the proposal itself, then please post it in the feedback thread.
> > The feedback thread will be the source for the review summary I
> > write at the end of this review round. I will post a link to that
> > thread immediately following this post. Just be sure to read and
> > understand the Reviewer Guidelines before posting there:
> >
> > https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
> >
> > The review period will end at 11:59 PM ET on February 20, or when
> > I make a post declaring it complete. Discussion in this thread
> > may continue beyond that point.
> >
> > At the end of Round 1, if further review is deemed necessary, the
> > DIP will be scheduled for another round of Community Review.
> > Otherwise, it will be queued for the Final Review and Formal
> > Assessment.
> >
> > Please stay on topic here. I will delete posts that are
> > completely off topic.
>
> Well, I'll say again that I don't like the idea of having named arguments in
> the language, because it makes the parameter names part of the API,
> resulting in yet more bikeshedding and yet another thing that can't be
> changed without breaking existing code. Once in a while, named arguments may
> be useful, but for the most part, they're useful because a function has way
> too many parameters, in which case, the function should have been designed
> differently.
>
> Unfortunately, since it's Walter who created the DIP, and a number of people
> do like the idea of named arguments, I expect that some form of this will
> make it in, but I still think that it's a bad idea.
>
> - Jonathan M Davis

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.

Here's a thought, which I haven't considered how it interacts with
this DIP deeply, but it should be on the table:

I do an immense amount of generative meta; generate wrappers, shims,
bindings etc, which wrap existing functions.
When the parameter names become part of the API, it means any such
meta must pay extra attention to properly mirror the parameter names,
and it must also carefully mirror the default args from the function
it's wrapping.
While most of my code takes care to do this anyway, there are cases
where it's unnecessary and inconvenient. Some tasks can be completed
with a tool like:

  ReturnType!originalFunction wrapper(alias
originalFunction)(Parameters!originalFunction args)
  {
    // special sauce...
    return originalFunction(args);
  }

It is possible to write many forms of glue this way. If we must mirror
the argument names and default arguments, you must fall back into
string mixin territory, and the code to emit the proper prototype is
complex and intensive.
In a named-arguments world, shim's like the one I showed above are no
longer valid where calling code would use named arguments.

I don't there is existing language that could make this possible:
  ReturnType!originalFunction wrapper(alias
originalFunction)(ParametersWithNamesAndDefaultArgs!originalFunction
args) { ... }

For me to get excited about this DIP sufficiently to offset my fears,
I need to know what it's for... and I don't.
If it's useful in the rare case where functions have way too many
parameters... personally, I resolve that by making my functions NOT
have way too many parameters.
I'm not sure that too-many-parameters is a pattern that should be
encouraged by the core language.

I would not to do this unless we can provide a really compelling case
to support its existence. I'm not satisfied that case exists here.
Maybe I missed it? (I'm not really following this topic)


More information about the Digitalmars-d mailing list