On Mon, Feb 10, 2020 at 01:39:12PM -0500, Steven Schveighoffer via Digitalmars-d wrote:
> On 2/10/20 1:36 PM, H. S. Teoh wrote:
> > On Mon, Feb 10, 2020 at 01:27:49PM -0500, Steven Schveighoffer via Digitalmars-d wrote:
> > > On 2/6/20 10:33 PM, Jonathan M Davis wrote:
> > > > 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.
> > > 
> > > I find this assertion lacking evidence.
> > > 
> > > How does one design a constructor that initializes all the fields of a type without including all the parameters to initialize that type?
> > [...]
> > 
> > Ostensibly, by encapsulating the parameters into a struct and passing said struct up the ctor chain. ;-)
> 
> So basically, for each type you need to define another type to pass parameters? Sounds... excessive ;)
> 
> And the benefit of having a POD struct to pass as a parameter to cut down on constructor parameters is... you get named parameters!
[...]

And there you have it, we already have named parameters. :-P  Albeit in a verbose, circumlocutious way. :-P


T

-- 
English has the lovely word "defenestrate", meaning "to execute by throwing someone out a window", or more recently "to remove Windows from a computer and replace it with something useful". :-) -- John Cowan

On Monday, 10 February 2020 at 18:27:49 UTC, Steven Schveighoffer wrote:
> On 2/6/20 10:33 PM, Jonathan M Davis wrote:
>> 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.
>
> I find this assertion lacking evidence.
>

Let me give a data point to the contrary. I am a C++ programmer at work and using CLion as my IDE. Recently CLion got the ability to display parameter names inline at call sides, that is given a function invocation

> foo(bar, baz, baraz)

of a function

> foo(parametertype1 parametername1, parametertype2 parametername2, ptype3 pname3)

it will be displayed like this with the parameter names in a slight gray:

> foo(parametername1: bar, parametername2: baz, pname3: baraz).

This already saved hours by preventing bugs and is unanimously considered an improvement by all my colleagues.

I am convinced named parameters can improve code quality and even expect that tooling will show up to insert them automatically in existing code, when they get into the language.

On Thu, Feb 6, 2020 at 7:34 PM Jonathan M Davis via Digitalmars-d <digitalmars-d@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)

On Monday, 10 February 2020 at 19:38:34 UTC, Manu wrote:
> If we must mirror
> the argument names and default arguments, you must fall back into string mixin territory

It is super simple. Consider this example:

---
int foo(string s = null, int a = 12) {
        return a + 12;
}
template wrapWithPrint(alias fn) {
        static if(is(typeof(fn) P == __parameters))
        auto wrapWithPrint(P params) {
                import std.stdio;
                writeln(params);
                auto ret = fn(params);
                writeln("returned: ", ret);
                return ret;
        }
        else static assert(0);
}
void main() {
        wrapWithPrint!foo();
        wrapWithPrint!foo("cool");
        wrapWithPrint!foo("cool", 20);
}
---

Default values and param names are included in the __parameters thing and just works if you use it directly.

I saw people overcomplicating this just a few hours ago too which is why I have this example ready. There's plenty of techniques to do this though I guess they aren't well known.

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@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

On Monday, 10 February 2020 at 19:49:24 UTC, 12345swordy 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@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

Meant to say "Named arguments prevent me from sending values to the wrong parameter"

On Monday, 10 February 2020 at 19:38:34 UTC, Manu 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

It's about my thoughts too. I think the question that needs to be solved by named parameters isn't strong enough.

Optional named parameters are handy but D already offers a variety of methods in order to pass those.

My fear as already other people pointed out is that named arguments will give D split personality. Some people adore named arguments and will use them for everything and others will not touch them. Libraries will use either methods and therefore make D feel schizophrenic.

Also what would the implementation complexity be if this would be implemented?

On Mon, Feb 10, 2020 at 11:50 AM 12345swordy via Digitalmars-d <digitalmars-d@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@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.
Do you have an answer to my actual criticisms? I feel like generative
meta is one of D's biggest features and selling points, and making
that very difficult feels like a material loss.

On Mon, Feb 10, 2020 at 12:25 PM IGotD- via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Monday, 10 February 2020 at 19:38:34 UTC, Manu 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
>
> It's about my thoughts too. I think the question that needs to be solved by named parameters isn't strong enough.
>
> Optional named parameters are handy but D already offers a variety of methods in order to pass those.
>
> My fear as already other people pointed out is that named arguments will give D split personality. Some people adore named arguments and will use them for everything and others will not touch them. Libraries will use either methods and therefore make D feel schizophrenic.
>
> Also what would the implementation complexity be if this would be implemented?

I doubt there's any meaningful implementation complexity inside DMD.

I showed examples of how this split personality will affect authors of
meta libraries.
Not being able to easily produce call shims or wrappers is a huge loss
without some sort of solution analogous to existing reflection tools.
I also think 'renaming a parameter (to improve API clarity) ==
breaking API change' is a frustrating world to live in.

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@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@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.