On Friday, 23 August 2019 at 19:57:05 UTC, a11e99z wrote:
> On Friday, 23 August 2019 at 19:48:59 UTC, Paul Backus wrote:
>> struct S { int a, b, c, d = 7; }
>> S w = { b:1, 3 };             // v.a = 0, v.b = 1, v.c = 3, v.d = 7
>
> unnamed arg after named is weird/error prone

It is fine, but only when the named argument has the same position as it would if it were unnamed.

void f(int a, b, c = 3, d = 4);
//Equivalent calls:
f(a: 1, 2, d: 5);
f(1, 2, 3, 5);

The purpose of writing `a: 1` is to describe the argument to the function at the call site, as programmers often won't look up the function signature just when reading code (e.g. on GitHub when they don't have the function open in their IDE).

Why not name b's argument too? Because that argument might be more obvious what it is. a might be passed a primitive literal but b might be passed a variable with the same name (or equivalent).

On Saturday, 24 August 2019 at 07:18:56 UTC, Nick Treleaven wrote:
> On Friday, 23 August 2019 at 19:57:05 UTC, a11e99z wrote:
>> On Friday, 23 August 2019 at 19:48:59 UTC, Paul Backus wrote:
>>> struct S { int a, b, c, d = 7; }
>>> S w = { b:1, 3 };             // v.a = 0, v.b = 1, v.c = 3, v.d = 7
>>
>> unnamed arg after named is weird/error prone
>
> It is fine, but only when the named argument has the same position as it would if it were unnamed.
>
> void f(int a, b, c = 3, d = 4);
> //Equivalent calls:
> f(a: 1, 2, d: 5);
> f(1, 2, 3, 5);
>
> The purpose of writing `a: 1` is to describe the argument to the function at the call site, as programmers often won't look up the function signature just when reading code (e.g. on GitHub when they don't have the function open in their IDE).
>
> Why not name b's argument too? Because that argument might be more obvious what it is. a might be passed a primitive literal but b might be passed a variable with the same name (or equivalent).

imo named args needed for one purpose only:
when u remember name of arg but don't remember which one (by natural order) it is.
when u don't remember name but only position most probably u also remember what is it at position before.
do u know other reasons for named args?

so from that point lets look at
> f(a: 1, 2, d: 5)
- u don't remember where a is, so named it
- u remember that b is second, so let it unnamed
  (dont remember 1st one but remember 2nd.. hmm)
- and other defaults, doesn't matter their order

same situation from another point: u reviewing code of ur junior. u see this. what u will do? most probably "don't do this! yes, u can but don't".
so why u tell me now that this is right way?

mixing named then unnamed then named again its just a new weird shit in lang.

PS
remember about DPP when tons of C++ code with tons of overloads will come to D

On Saturday, 24 August 2019 at 07:54:57 UTC, a11e99z wrote:
> On Saturday, 24 August 2019 at 07:18:56 UTC, Nick Treleaven wrote:
>> On Friday, 23 August 2019 at 19:57:05 UTC, a11e99z wrote:
>>> On Friday, 23 August 2019 at 19:48:59 UTC, Paul Backus wrote:
>
> imo named args needed for one purpose only:
> when u remember name of arg but don't remember which one (by natural order) it is.
> when u don't remember name but only position most probably u also remember what is it at position before.
> do u know other reasons for named args?
>
and of course skip args with default values that suit us

On Saturday, 24 August 2019 at 06:17:07 UTC, Walter Bright wrote:
> On 8/23/2019 10:00 PM, a11e99z wrote:
>> so which one should be called in sample below?
>> 
>> import std.stdio;
>> void foo(int a, int b) {writeln("0");}
>> void foo(int b, double a) {writeln("1");}
>> void main()
>> {
>>      foo(b: 10, 0);
>> }
>
> According to my suggestion, "1" is unambiguously selected.
>
> https://digitalmars.com/d/archives/digitalmars/D/DIP_1019--Named_Arguments_Lite--Community_Review_Round_2_327714.html#N327755

when I look at snoopy(..) code, only one name comes to mind "quantum entanglement".

ask yourself: why need named args for usual programmers?
my assumption:
- skip some args with default values
  u have list of defaulted values, most of them suit u, and some u want to change.
- user remember arg name but don't remember it position.

lets say this 2 points cover 90% of use cases

- u remember position of arg with it meaning, but don't remember it name, and u don't remember meanings of args before the one.
another 10%

so, to make happy 90% of desirous user for named args u can just add to lang:
named args follows by positional args (not vice versa, no mixing)
well:
- it simple to add it to compiler
  args after positionals have prefix "name:" that should be assigned to right var
  and check that all non-defaulted args are set.
  and check that no args set more than once.
- it simple to understand it, no need to know quasiparticles of compiler

10% other users should to see func definition and fill args in right order or with right names.
it is fair.
other users should understand their code too if they want(learning) or should(review).

in snoopy-case I see next:
- need to add __traits( snoopy(s:s, t:t, i)) that returns full function description that will be called by compiler.
- probably overloads will become dangerous points of D programming.
- new WTF Waves at forum messages.
- remember about DPP when will be added to D sea of overloads C++ functions.

last one:
named args should be done for (most of) users, not for researching D-dark-deeps by gods.

On Saturday, 24 August 2019 at 06:17:07 UTC, Walter Bright wrote:
> On 8/23/2019 10:00 PM, a11e99z wrote:
>> so which one should be called in sample below?
>> 
>> import std.stdio;
>> void foo(int a, int b) {writeln("0");}
>> void foo(int b, double a) {writeln("1");}
>> void main()
>> {
>>      foo(b: 10, 0);
>> }
>
> According to my suggestion, "1" is unambiguously selected.
>
> https://digitalmars.com/d/archives/digitalmars/D/DIP_1019--Named_Arguments_Lite--Community_Review_Round_2_327714.html#N327755

when I look at snoopy(..) code, only one name comes to mind "quantum entanglement".

some definitions (and sorry for my English):
defaulted args=args that has default values
non-defaulted/positional args=args that has not default values and they should be assigned by user
named args=args with names. opposite to them=unnamed args.

ask yourself: why usual programmers needs named args?
my assumption:
- skip some args with default values
  u have list of defaulted values, most of them suit u, and some u want to change.
- and user remember arg name but don't remember it position.

lets say this 2 points cover 90% of use cases

- u remember position of arg with it meaning, but don't remember it name, and u don't remember meanings of args before the one
  probably u will assign values to "before" args by name. well, u remember name of it but not meaning. ok.
- something more weird here...
last 10%

so, to make happy 90% of user that wants named args u can just add to lang:
named args follows by unnamed args (not vice versa, no mixing)

- it simple to add it to compiler
  positional goes first (order is matter), named goes after (order doesn't matter)
  ensure that all non-defaulted args are set by pos or by name.
  ensure that no args set more than once.
- it simple to understand, no need to know quasiparticles of compiler.

10% other users should to see func definition and fill args in right order or with right names.
it is fair.
other users should understand their code too if they(others) want (for learning) or should (review/pr).

your snoopy sample is mind killer and just mess.
and reality will be more horrendous.
u will not write such code yourself, so why u gives to others gun to shoot not only their legs but others heads?

in snoopy-case I see next:
- need to add __traits( snoopy(s:s, i, t:t)) that returns full function description that will be called by compiler for such code.
- probably overloads will become dangerous pond of D programming.
- most of us will don't understand such named code without help from IDE. bye simple text editors.
- new WTF Waves at forum messages, more questions about details of naming.
- remember about DPP when will be added to D sea of overloads C++ functions.

last one:
named args should be done for (most of) users, not for researching D-dark-deeps by gods or quantum nerds.
u have deal in compiler with people not with bytes.

and return back to question "why usual programmers needs named args?"
why no complains from C# programmers about pet/toy/too_constrained named args?
I think cuz it enough for everything/everybody and behind that line lives dragons.

On Friday, 23 August 2019 at 23:46:43 UTC, Yuxuan Shui wrote:
> On Friday, 23 August 2019 at 18:35:26 UTC, bachmeier wrote:
>> On Friday, 23 August 2019 at 17:42:14 UTC, H. S. Teoh wrote:
>>
>>> But this:
>>>
>>> 	foo(x: 4, y: 8, z: 9,
>>> 		screen: scr1, widget: wg2,
>>> 		options: opts, menu: menu3);
>>>
>>> is no worse than 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);
>>
>> What that leads to is this:
>>
>> foo(x: 4, y: 8, z: 9,
>> 	screen: scr1, widget: wg2,
>> 	options: opts, menu: menu3);
>> foo(x: 4, y: 8, z: 9,
>> 	screen: scr2, widget: wg2,
>> 	options: opts, menu: menu3);
>> foo(x: 4, y: 8, z: 9,
>> 	screen: scr1, widget: wg1,
>> 	options: opts, menu: menu3);
>>
>> You've got a combination of extreme verbosity, hard-to-read code, and a prolific bug generation machine.
>
> How is that hard to read?

I suppose that's up to each programmer to define, but I don't see anything fun about having to look at eight named parameters to see which have changed from one call to the next. If you're doing a simulation with six different configurations, you don't want to have to specify all of the parameters every time, but the "easy approach" quickly becomes the default, and that's exactly what you'd be stuck with.

> Personally I think the FooParams version is more verbose and harder to read.

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. It also saves a lot of typing/copying and pasting. Large blocks of nearly duplicated code is a terrible thing that should be avoided at all costs. That's what you get when you have a large number of function arguments, and it's bad practice. There's always a cost to adding syntax (think about the person learning the language) so new syntax better pay big dividends.

> Also the FooParams version forces default values on all parameters so when you forgot to specify one of the parameters

To be honest, I don't understand why a struct would force default parameters on you, but even if it did, that's a problem with default parameters, not structs. You'd have the same thing if you forgot to specify one of the parameters of a function call. Which, I'll note, is a whole lot easier to do when you're engaged in copy and paste because function calls are not reusable.

On Friday, 23 August 2019 at 10:54:11 UTC, 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.
>
> Anyone intending to post feedback in this thread is expected to be familiar with the reviewer guidelines:
>
> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>
> The current revision of the DIP for this review is located here:
>
> https://github.com/dlang/DIPs/blob/3bc3469a841b87517a610f696689c8771e74d9e5/DIPs/DIP1019.md
>
> In it you'll find a link to and summary of the previous review rounds. This round of review will continue until 11:59 pm ET on September 6 unless I call it off before then.
>
> Thanks in advance for your participation.

I have already said my piece on this. However this dip is coming across as a diet coke version of an actual named arguments in the c#, which won't surprise me if this is rejected on the basis that it didn't do enough.

-Alex

On Friday, 23 August 2019 at 17:49:17 UTC, Andrei Alexandrescu wrote:
> Funny you should mention this, because the obvious problem is this doesn't work:
>
> glfwCreateWindow(1280, 720, "my window", parentWindow: null, fullScreenMonitor: null);

That's not a big problem.
If you re-order it, someone might re-use that line in a project with a different glfw binding (e.g. using DPP instead of bindbc) and it won't work anymore. He'd have to reverse-engineer the original order to be able to figure out which parameters were passed where instead of just updating / removing the named parameters.

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?

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?