On Saturday, 24 August 2019 at 16:36:51 UTC, Andrei Alexandrescu wrote:
> We have two competing proposals for named arguments. Walter's alternative has been consistently ignored, though I notice Walter mentioned it more than once. That would be totally fine if the proposals were better, but it doesn't take much to figure Walter's is obviously way better, simpler, and integrates beautifully within the existing language.
>
> This entire dynamics strikes me as massively counterproductive. Why are we doing this?

I found Walter's proposal to be such an obvious winner, that I expected it to be inevitable. I now see this is not the case.

Let me correct that: I vote for Walter's solution.

On Saturday, 24 August 2019 at 16:36:51 UTC, Andrei Alexandrescu wrote:
> On 8/23/19 6:23 PM, Walter Bright wrote:
>> On 8/23/2019 3:54 AM, Mike Parker wrote:
>>> DIP 1019, "Named Arguments Lite", is now ready for Final Review. This is the last chance for community feedback before the DIP is handed off to Walter and Átila for the Formal Assessment.
>> 
>> 
>> I reiterate my previous opinion:
>> 
>> https://digitalmars.com/d/archives/digitalmars/D/DIP_1019--Named_Arguments_Lite--Community_Review_Round_2_327714.html#N327755
>
> We have two competing proposals for named arguments. Walter's alternative has been consistently ignored, though I notice Walter mentioned it more than once. That would be totally fine if the proposals were better, but it doesn't take much to figure Walter's is obviously way better, simpler, and integrates beautifully within the existing language.
>
> This entire dynamics strikes me as massively counterproductive. Why are we doing this?

I think most of us agree Walter's proposal is better. If Walter or Atila say they cannot support the current proposal, that will kill it, but that hasn't happened. Walter's proposal should have killed this DIP the first time.

On Saturday, 24 August 2019 at 13:57:17 UTC, bachmeier wrote:
> Maybe an example will make my point more clear. You start with this:
>
> FooParams params;
> params.x = 4;
> params.y = 8;
> params.z = 9;
> params.screen = scr1;
> params.widget = wg2;
> params.options = opts;
> params.menu = menu3;
> foo(params);
>
> Then you change a single parameter and call foo again:
>
> params.x = 5;
> foo(params);
>
> It's crystal clear what is the difference in those two calls to foo. No need to parse a large list of arguments and hope you get right which parameters changed and which didn't.

While we're all throwing around overly complicated examples that distract from the need for named arguments, here's another:

void func( int a, float b, string c, int d, double e )
{
    import std.stdio : writeln;
    writeln( a, ", ", b, ", ", c, ", ", d, ", ", e );
}

struct FromTuple( T... )
{
    T vals;
}

int main()
{
    static if( is( typeof( func ) Params == __parameters ) )
    {
        FromTuple!Params p = { 1, 2.0f, "3", 4, 5.0 };
        func( p.tupleof );
        p.tupleof[ 2 ] = "three";
        func( p.tupleof );
    }

    return 0;
}

-----

Both the original example and the quoted example are belabored to prove a point, and hey, turns out programmers can do tons of weird stuff that makes code hard to read but still works perfectly.

Didn't they teach anyone about API complexity in compsci 101? About how adding a struct means you now need to read multiple places in source to understand how to use something?

But now I'm digressing. The point of named arguments is not to dictate programming standards. It is simply to make overriding defaults easier. And you can look no further to my talk at DConf this year to see what I think of providing default behavior with overrides.

-----

Also, I agree with the sentiment in general in this thread. Don't half-bake the implementation because you think it'll get accepted and in use quicker. Do it properly, basically just like Walter's suggestions.

On 8/24/19 5:00 PM, bachmeier wrote:
> On Saturday, 24 August 2019 at 16:36:51 UTC, Andrei Alexandrescu wrote:
>> On 8/23/19 6:23 PM, Walter Bright wrote:
>>> On 8/23/2019 3:54 AM, Mike Parker wrote:
>>>> DIP 1019, "Named Arguments Lite", is now ready for Final Review. This is the last chance for community feedback before the DIP is handed off to Walter and Átila for the Formal Assessment.
>>>
>>>
>>> I reiterate my previous opinion:
>>>
>>> https://digitalmars.com/d/archives/digitalmars/D/DIP_1019--Named_Arguments_Lite--Community_Review_Round_2_327714.html#N327755 
>>>
>>
>> We have two competing proposals for named arguments. Walter's alternative has been consistently ignored, though I notice Walter mentioned it more than once. That would be totally fine if the proposals were better, but it doesn't take much to figure Walter's is obviously way better, simpler, and integrates beautifully within the existing language.
>>
>> This entire dynamics strikes me as massively counterproductive. Why are we doing this?
> 
> I think most of us agree Walter's proposal is better. If Walter or Atila say they cannot support the current proposal, that will kill it, but that hasn't happened. Walter's proposal should have killed this DIP the first time.

The sheer fact he reiterated his proposal in response to this DIP killed the DIP.

On 8/24/19 1:00 PM, 12345swordy wrote:
> On Saturday, 24 August 2019 at 16:36:51 UTC, Andrei Alexandrescu wrote:
>> On 8/23/19 6:23 PM, Walter Bright wrote:
>>> On 8/23/2019 3:54 AM, Mike Parker wrote:
>>>> [...]
>>>
>>>
>>> I reiterate my previous opinion:
>>>
>>> https://digitalmars.com/d/archives/digitalmars/D/DIP_1019--Named_Arguments_Lite--Community_Review_Round_2_327714.html#N327755 
>>>
>>
>> We have two competing proposals for named arguments. Walter's alternative has been consistently ignored, though I notice Walter mentioned it more than once. That would be totally fine if the proposals were better, but it doesn't take much to figure Walter's is obviously way better, simpler, and integrates beautifully within the existing language.
>>
>> This entire dynamics strikes me as massively counterproductive. Why are we doing this?
> 
> ...because no one write a DIP on walter suggestions?

That's why I say - it's so wasteful. Any of the current proposers could have written a quality DIP in a fraction of the time it took them to write their inferior DIPs, get it in, and get full credit for it. The mind boggles.

On Saturday, 24 August 2019 at 07:54:57 UTC, a11e99z wrote:
> do u know other reasons for named args?

Yes, as I explained in my comment.

On Saturday, 24 August 2019 at 21:00:08 UTC, bachmeier wrote:
> On Saturday, 24 August 2019 at 16:36:51 UTC, Andrei Alexandrescu wrote:
>> [...]
>
> I think most of us agree Walter's proposal is better. If Walter or Atila say they cannot support the current proposal, that will kill it, but that hasn't happened. Walter's proposal should have killed this DIP the first time.

Walter basically said as much. As for me, I thought Walter's simpler proposal is so obvious that I didn't have to say anything.

On Saturday, 24 August 2019 at 01:09:48 UTC, Jonathan M Davis wrote:
> Personally, I'm against named arguments in general. They make the parameter names part of the API, which adds another set of names that you have to get right up front and which will be bike-shedded to death.

Errors in function names happen too.

> The _only_ use case IMHO where they add any real value is when you have a long parameter list where most of the parameters having default arguments.

Another use case is replacing the Flag thing. When a function has only one parameter and it's has primitive type, names argument will have merit.

On Saturday, 24 August 2019 at 16:36:51 UTC, Andrei Alexandrescu wrote:
> We have two competing proposals for named arguments. Walter's alternative has been consistently ignored, though I notice Walter mentioned it more than once. That would be totally fine if the proposals were better, but it doesn't take much to figure Walter's is obviously way better, simpler, and integrates beautifully within the existing language.
>
> This entire dynamics strikes me as massively counterproductive. Why are we doing this?

I had an impression that field matching rules are only obvious to the compiler. Is it simpler in the sense that the code written for structs can be used for arguments?

And description of algorithm is unclear https://dlang.org/spec/struct.html#static_struct_init