www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP 1019--Named Arguments Lite--Final Review

reply Mike Parker <aldacron gmail.com> writes:
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.
Aug 23
next sibling parent reply Daniel N <no public.email> writes:
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 oppose the empty name feature... "Parameter name omission If a function is defined with some of its parameter names omitted, arguments to those parameters can be labeled with an empty name." I don't see how it could be reasonably implemented, nor what problem it solves. Consider: void fun(int, int); fun(:1, :2); // ???
Aug 23
parent reply Maximillian <maximilliancart outlook.com> writes:
On Friday, 23 August 2019 at 11:24:25 UTC, Daniel N wrote:
 I oppose the empty name feature...
I'm wondering... this DIP say "Final Review" and in this topic I see people complaining about some features like it was added recently, and if this is the case than this DIP process is broken. "Final" would be like an adjust here and there but for what I see that's not the case here. Am I missing something? Max.
Aug 23
parent Mike Parker <aldacron gmail.com> writes:
On Friday, 23 August 2019 at 13:23:22 UTC, Maximillian wrote:
 On Friday, 23 August 2019 at 11:24:25 UTC, Daniel N wrote:
 I oppose the empty name feature...
I'm wondering... this DIP say "Final Review" and in this topic I see people complaining about some features like it was added recently, and if this is the case than this DIP process is broken. "Final" would be like an adjust here and there but for what I see that's not the case here. Am I missing something? Max.
The feature was present in the previous revision and the DIP author decided not to remove it. If you wish to discuss the DIP process further, please start a new thread. I will remind everyone to please keep comments in this thread focused on the DIP itself, as outlined in the document I linked in the first post: https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md I will be deleting any further off topic posts and pasting them into a separate thread. Thanks!
Aug 23
prev sibling next sibling parent Dennis <dkorpel gmail.com> writes:
On Friday, 23 August 2019 at 10:54:11 UTC, Mike Parker wrote:
 Thanks in advance for your participation.
I like how this DIP evolved. The first version looked very unattractive, but it's shaping up to be an elegant proposal. My points for this version:
 In addition, this proposal has the added benefit of protecting 
 against silent breakage in cases when a function's parameters 
 are repurposed and renamed. For example:
Even with named arguments, I wouldn't dare to change the parameter meaning without changing the type. If someone doesn't use named parameters he gets silent breakage anyways. I don't think this is a strong argument in favor of named arguments. The Prior Work section shows some examples of named parameters in other languages, but it doesn't tell why you chose these languages / why these languages chose their design. I like the solution to parameter name lock-in, it uses existing languages features for an elegant solution.
 A survey of name changes in popular libraries done by the 
 authors of a similar proposal introducing named arguments to 
 C++ suggests this kind of breakage should be rare.
Can you add a reference to this? What is the rationale behind variadic functions `args[0]: "string"` or paramater name omission `fun(:10)`? The grammar changes propose an addition to `ArgumentList`. This production rule is used in other places than function calls though, so this is allowed by the new grammar: ``` mixin(name: "x = 3;"); ```
Aug 23
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
Remove the sections about variadic functions and unnamed 
parameters.
Aug 23
parent a11e99z <black80 bk.ru> writes:
On Friday, 23 August 2019 at 12:04:39 UTC, Kagamin wrote:
 Remove the sections about variadic functions and unnamed 
 parameters.
+1
Aug 23
prev sibling next sibling parent a11e99z <black80 bk.ru> writes:
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:

 The current revision of the DIP for this review is located here:

 https://github.com/dlang/DIPs/blob/3bc3469a841b87517a610f696689c8771e74d9e5/DIPs/DIP1019.md
now you have to come up with beautiful names for the parameters. cnt and fmt are illegal. although this is a headache, but the language will become more beautiful.
Aug 23
prev sibling next sibling parent Mike Franklin <slavo5150 yahoo.com> writes:
On Friday, 23 August 2019 at 10:54:11 UTC, Mike Parker wrote:

 The current revision of the DIP for this review is located here:

 https://github.com/dlang/DIPs/blob/3bc3469a841b87517a610f696689c8771e74d9e5/DIPs/DIP1019.md
==== "Named arguments proposed by this DIP have no effect on the ordering of arguments in function calls." "Named arguments proposed by this DIP do not allow default parameters to be skipped." "Variadic arguments can be labeled with the name of the variadic parameter and a subscript." For each of those statements quoted above, I think it would help the DIP to present an example with code and potential compiler output. ==== "If a function is defined with some of its parameter names omitted, arguments to those parameters can be labeled with an empty name." --- void fun(int); fun(:10); --- That seems weird to me. Why even allow the ":10" syntax? I recommend adding some justification to the DIP. Mike
Aug 23
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 8/23/19 6: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.
 
 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/3bc3469a841b87517a610f696689c8771e74
9e5/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.
The DIP is well researched and clearly written. Kudos. Sadly I oppose it on the following grounds: "Named arguments proposed by this DIP have no effect on the ordering of arguments in function calls." "Named arguments proposed by this DIP do not allow default parameters to be skipped." These two limitations are as useful and help each other as much as a nausea and a cough. Large parameter lists of which most have reasonable defaults is a marquee use case of named arguments. A proposal that works itself out of that opportunity cannot and should not be acceptable. I was unconvinced by the argument that these can be added later. Language design is peculiar in that incrementalism doesn't work well - it must come all at once. There are exceptions and arguments that can be made but there's overwhelming evidence that incremental language design is just not a good way to go about things.
Aug 23
next sibling parent ixid <nuaccount gmail.com> writes:
On Friday, 23 August 2019 at 15:01:20 UTC, Andrei Alexandrescu 
wrote:
 Sadly I oppose it on the following grounds:

 "Named arguments proposed by this DIP have no effect on the 
 ordering of arguments in function calls."

 "Named arguments proposed by this DIP do not allow default 
 parameters to be skipped."

 These two limitations are as useful and help each other as much 
 as a nausea and a cough.
As Andrei said these are the two features I would look for in named arguments and this doesn't have either. It would be better to go back to the drawing board.
Aug 23
prev sibling next sibling parent reply Dennis <dkorpel gmail.com> writes:
On Friday, 23 August 2019 at 15:01:20 UTC, Andrei Alexandrescu 
wrote:
 Large parameter lists of which most have reasonable defaults is 
 a marquee use case of named arguments. A proposal that works 
 itself out of that opportunity cannot and should not be 
 acceptable.
I'm personally not a fan of those argument lists the size of the Magna Cartas like you see in Python libraries: https://matplotlib.org/3.1.1/api/_as_gen/matplotlib.lines.Line2D.html#matplotlib.lines.Line2D I don't see it as a loss that this DIP doesn't enable those in D. If your function takes more than 6 arguments you should really consider creating a struct with configuration data. On Friday, 23 August 2019 at 15:01:20 UTC, Andrei Alexandrescu wrote:
 I was unconvinced by the argument that these can be added 
 later. Language design is peculiar in that incrementalism 
 doesn't work well - it must come all at once. There are 
 exceptions and arguments that can be made but there's 
 overwhelming evidence that incremental language design is just 
 not a good way to go about things.
In many cases (like the recent scope/ safe related proposals) I agree that implementing only part of a design has little value, but in this case the proposal has merits even in this limited form. Take for example this line: glfwCreateWindow(1280, 720, "my window", null, null); You can easily guess what the first three arguments are, but what about those two nulls? It could be made clearer like this: glfwCreateWindow(1280, 720, "my window", fullScreenMonitor: null, parentWindow: null); You can't leave `fullScreenMonitor` to the default while passing `parentWindow` with this DIP, but writing out that argument doesn't seem like a big loss to me. And even if it is, limitations can easily be lifted without much friction. If it turns out that reordering causes problems down the line, deprecating them would be more of a hassle.
Aug 23
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Aug 23, 2019 at 04:19:51PM +0000, Dennis via Digitalmars-d wrote:
 On Friday, 23 August 2019 at 15:01:20 UTC, Andrei Alexandrescu wrote:
 Large parameter lists of which most have reasonable defaults is a
 marquee use case of named arguments. A proposal that works itself
 out of that opportunity cannot and should not be acceptable.
Exactly the same objections I have against this DIP. OT1H it's trying to get named arguments into the language, but OTOH it takes out what I would consider to be two of the most important reasons to *have* named arguments: skipping default parameters, and out-of-order argument passing. Therefore, it essentially nullifies its own raison d'etre.
 I'm personally not a fan of those argument lists the size of the Magna
 Cartas like you see in Python libraries:
 https://matplotlib.org/3.1.1/api/_as_gen/matplotlib.lines.Line2D.html#matplotlib.lines.Line2D
 I don't see it as a loss that this DIP doesn't enable those in D. If
 your function takes more than 6 arguments you should really consider
 creating a struct with configuration data.
[...] But this DIP neither enables nor disables inordinately long parameter lists: the language already allows them! The only thing worse than an overly-long parameter list is one in which you cannot (easily) tell which argument corresponds with which parameter, and that's something this DIP would fix (by letting you name the arguments so that they are self-documenting). So your argument doesn't really detract from this DIP. Furthermore, if this DIP hadn't shot itself in its own foot by not allowing out-of-order argument passing and skipping default parameters, then it would have actually made overly-long parameter lists actually *acceptable*, in the sense that the function could just supply default values for most of the parameters, and the caller can just name and pass the few arguments that it wants to be different from the defaults, and the rest don't have to be explicitly specified. T -- If you're not part of the solution, you're part of the precipitate.
Aug 23
next sibling parent reply bachmeier <no spam.net> writes:
On Friday, 23 August 2019 at 16:47:14 UTC, H. S. Teoh wrote:
 I'm personally not a fan of those argument lists the size of 
 the Magna
 Cartas like you see in Python libraries:
 https://matplotlib.org/3.1.1/api/_as_gen/matplotlib.lines.Line2D.html#matplotlib.lines.Line2D
 I don't see it as a loss that this DIP doesn't enable those in 
 D. If
 your function takes more than 6 arguments you should really 
 consider
 creating a struct with configuration data.
[...] But this DIP neither enables nor disables inordinately long parameter lists: the language already allows them! The only thing worse than an overly-long parameter list is one in which you cannot (easily) tell which argument corresponds with which parameter, and that's something this DIP would fix (by letting you name the arguments so that they are self-documenting). So your argument doesn't really detract from this DIP.
Hopefully we don't make changes to the language in order to reduce the cost of bad programming practice. There's a real cost to encouraging long parameter lists, because while the "usual" case isn't so bad: foo(x: 4, y: 8) the case where you specify nine parameters is quite ugly, spilling onto multiple lines and making it hard to read. IMO, it's okay to make language design decisions assuming existing data structures (structs in this case) will be used when they're appropriate.
Aug 23
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Aug 23, 2019 at 05:16:16PM +0000, bachmeier via Digitalmars-d wrote:
 On Friday, 23 August 2019 at 16:47:14 UTC, H. S. Teoh wrote:
[...]
 But this DIP neither enables nor disables inordinately long
 parameter lists: the language already allows them!  The only thing
 worse than an overly-long parameter list is one in which you cannot
 (easily) tell which argument corresponds with which parameter, and
 that's something this DIP would fix (by letting you name the
 arguments so that they are self-documenting).  So your argument
 doesn't really detract from this DIP.
Hopefully we don't make changes to the language in order to reduce the cost of bad programming practice. There's a real cost to encouraging long parameter lists, because while the "usual" case isn't so bad: foo(x: 4, y: 8) the case where you specify nine parameters is quite ugly, spilling onto multiple lines and making it hard to read.
[...] 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); T -- Just because you survived after you did it, doesn't mean it wasn't stupid!
Aug 23
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 8/23/19 1:42 PM, H. S. Teoh wrote:
 On Fri, Aug 23, 2019 at 05:16:16PM +0000, bachmeier via Digitalmars-d wrote:
 On Friday, 23 August 2019 at 16:47:14 UTC, H. S. Teoh wrote:
[...]
 But this DIP neither enables nor disables inordinately long
 parameter lists: the language already allows them!  The only thing
 worse than an overly-long parameter list is one in which you cannot
 (easily) tell which argument corresponds with which parameter, and
 that's something this DIP would fix (by letting you name the
 arguments so that they are self-documenting).  So your argument
 doesn't really detract from this DIP.
Hopefully we don't make changes to the language in order to reduce the cost of bad programming practice. There's a real cost to encouraging long parameter lists, because while the "usual" case isn't so bad: foo(x: 4, y: 8) the case where you specify nine parameters is quite ugly, spilling onto multiple lines and making it hard to read.
[...] 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);
Exactly. It seems that for short lists (2-3 arguments) naming would be a net negative (add notational overhead when there's little possibility of a confusion to start with). Then, when the list gets longer it actually makes matters _worse_ because it disallows skipping of defaulted arguments. This can't go.
Aug 23
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Aug 23, 2019 at 01:59:38PM -0400, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 8/23/19 1:42 PM, 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);
Exactly. It seems that for short lists (2-3 arguments) naming would be a net negative (add notational overhead when there's little possibility of a confusion to start with). Then, when the list gets longer it actually makes matters _worse_ because it disallows skipping of defaulted arguments.
Yes, in the case of a proxy argument struct, you can define defaults in the struct definition and just set the parameters you want, which is a better solution than this DIP.
 This can't go.
I think the way to move forward is to expand the scope of this DIP to allow reordering and skipping over default arguments. I just don't see the benefit of going through all the trouble of the DIP process and subsequent implementation work, only to end up with a half-hearted feature that doesn't even offer these two most desirable things of a named argument implementation. T -- Without outlines, life would be pointless.
Aug 23
parent reply Dennis <dkorpel gmail.com> writes:
On Friday, 23 August 2019 at 18:41:56 UTC, H. S. Teoh wrote:
 I just don't see the benefit of going through all the trouble 
 of the DIP process and subsequent implementation work, only to 
 end
 up with a half-hearted feature that doesn't even offer these
 two most desirable things of a named argument implementation.
The current DIP has less complexity. What if you go through all the trouble of implementing it only to find out some tricky edge cases you didn't think about? E.g. what does this code do: ``` import std.stdio; void foo(int a, double b) {writeln("0");} void foo(int b, int a) {writeln("1");} void main() { foo(b: 10, 0); } ``` You might have an obvious intuition for this situation ("that should be an error!"), but maybe there are other ones.
Aug 23
next sibling parent reply Dennis <dkorpel gmail.com> writes:
On Friday, 23 August 2019 at 19:30:40 UTC, Dennis wrote:
 ```
 import std.stdio;
 void foo(int a, double b) {writeln("0");}
 void foo(int b, int a) {writeln("1");}

 void main()
 {
     foo(b: 10, 0);
 }
 ```
Correction: ``` 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); } ``` The point is, is an exact type match more important than parameter order match?
Aug 23
next sibling parent a11e99z <black80 bk.ru> writes:
On Friday, 23 August 2019 at 19:33:07 UTC, Dennis wrote:
 On Friday, 23 August 2019 at 19:30:40 UTC, Dennis wrote:
 ```
 import std.stdio;
 void foo(int a, double b) {writeln("0");}
 void foo(int b, int a) {writeln("1");}

 void main()
 {
     foo(b: 10, 0);
 }
 ```
Correction: ``` 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); } ``` The point is, is an exact type match more important than parameter order match?
as I said https://forum.dlang.org/post/wlcwgrfotdfpojbtktne forum.dlang.org - named args follows by unnamed args, not vice versa, no mixing
Aug 23
prev sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 23 August 2019 at 19:33:07 UTC, Dennis wrote:
 Correction:
 ```
 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);
 }
 ```

 The point is, is an exact type match more important than 
 parameter order match?
Walter's proposal from the previous discussion was that named parameters should use the same rules for reordering as named struct initialization [1] (which in turn are the same rules used by designated initializers in C99 [2]). So in this case, the second overload would be called, because it's the only one with a parameter after `b`. Even if these aren't your favorite rules, I think there's a lot to be said for consistency. [1] https://dlang.org/spec/struct.html#static_struct_init [2] http://port70.net/~nsz/c/c99/n1256.html#6.7.8p17
Aug 23
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 8/23/19 3:48 PM, Paul Backus wrote:
 On Friday, 23 August 2019 at 19:33:07 UTC, Dennis wrote:
 Correction:
 ```
 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);
 }
 ```

 The point is, is an exact type match more important than parameter 
 order match?
Walter's proposal from the previous discussion was that named parameters should use the same rules for reordering as named struct initialization [1] (which in turn are the same rules used by designated initializers in C99 [2]). So in this case, the second overload would be called, because it's the only one with a parameter after `b`. Even if these aren't your favorite rules, I think there's a lot to be said for consistency. [1] https://dlang.org/spec/struct.html#static_struct_init [2] http://port70.net/~nsz/c/c99/n1256.html#6.7.8p17
Noice!
Aug 23
prev sibling parent reply a11e99z <black80 bk.ru> writes:
On Friday, 23 August 2019 at 19:48:59 UTC, Paul Backus wrote:
 On Friday, 23 August 2019 at 19:33:07 UTC, Dennis wrote:

 Walter's proposal from the previous discussion was that named 
 parameters should use the same rules for reordering as named 
 struct initialization [1] (which in turn are the same rules 
 used by designated initializers in C99 [2]). So in this case, 
 the second overload would be called, because it's the only one 
 with a parameter after `b`.

 Even if these aren't your favorite rules, I think there's a lot 
 to be said for consistency.

 [1] https://dlang.org/spec/struct.html#static_struct_init
 [2] http://port70.net/~nsz/c/c99/n1256.html#6.7.8p17
 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. u should to know right order (here names are ordered so it not usual case) imo better forbid named args before unnamed OR unnamed args after named
 unnamed, unnamed, unnamed, named, named, named
Aug 23
parent reply Nick Treleaven <nick geany.org> writes:
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).
Aug 24
parent reply a11e99z <black80 bk.ru> writes:
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
Aug 24
next sibling parent a11e99z <black80 bk.ru> writes:
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
Aug 24
prev sibling parent Nick Treleaven <nick geany.org> writes:
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.
Aug 25
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 8/23/19 3:30 PM, Dennis wrote:
 On Friday, 23 August 2019 at 18:41:56 UTC, H. S. Teoh wrote:
 I just don't see the benefit of going through all the trouble of the 
 DIP process and subsequent implementation work, only to end
 up with a half-hearted feature that doesn't even offer these
 two most desirable things of a named argument implementation.
The current DIP has less complexity. What if you go through all the trouble of implementing it only to find out some tricky edge cases you didn't think about?
That's exactly why we have a process that replaces seat-of-the-pants language design.
 E.g. what does this code do:
 ```
 import std.stdio;
 void foo(int a, double b) {writeln("0");}
 void foo(int b, int a) {writeln("1");}
 
 void main()
 {
      foo(b: 10, 0);
 }
 ```
 
 You might have an obvious intuition for this situation ("that should be 
 an error!"), but maybe there are other ones.
Good point. This is what the DIP review cycle is for.
Aug 23
parent a11e99z <black80 bk.ru> writes:
On Friday, 23 August 2019 at 19:55:31 UTC, Andrei Alexandrescu 
wrote:
 On 8/23/19 3:30 PM, Dennis wrote:
 On Friday, 23 August 2019 at 18:41:56 UTC, H. S. Teoh wrote:
 E.g. what does this code do:
 ```
 import std.stdio;
 void foo(int a, double b) {writeln("0");}
 void foo(int b, int a) {writeln("1");}
 
 void main()
 {
      foo(b: 10, 0);
 }
 ```
 
 You might have an obvious intuition for this situation ("that 
 should be an error!"), but maybe there are other ones.
Good point. This is what the DIP review cycle is for.
does rule "named args after unnamed" solve this problem? foo( b:10, 0 ); // C# ERROR: Named arguments must appear after the positional arguments foo( 0, b:10); // foo( int, int) no doubts
Aug 23
prev sibling next sibling parent reply a11e99z <black80 bk.ru> writes:
On Friday, 23 August 2019 at 17:59:38 UTC, Andrei Alexandrescu 
wrote:
 On 8/23/19 1:42 PM, H. S. Teoh wrote:
 On Fri, Aug 23, 2019 at 05:16:16PM +0000, bachmeier via 
 Digitalmars-d wrote:
 On Friday, 23 August 2019 at 16:47: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);
Exactly. It seems that for short lists (2-3 arguments) naming would be a net negative (add notational overhead when there's little possibility of a confusion to start with). Then, when the list gets longer it actually makes matters _worse_ because it disallows skipping of defaulted arguments. This can't go.
C# version (C# online REPL https://repl.it/repls/KnowingDeliriousLifecycles) ============================== using System; class MainClass { static void fun( int arg1, string arg2, double arg3, string def1 ="one", int def2 = 2) { Console.WriteLine( $"fun( {arg1}, {arg2}, {arg3}, {def1}, {def2} )"); } public static void Main (string[] args) { // ok fun( arg3:3.14, arg2:"world", arg1:789); // Named arguments must appear after the positional arguments //fun( 123, arg2:"world", 2.72, def1:"hello" ); // ok now fun( 123, arg2:"hello", arg3:9.8, def2:-2); // defaulted args can be skipped in any order fun( 123, "hello", 6e23, def1:"world"); fun( 123, "hello", def2:-2, arg3:3e8); //The best overloaded method match for `MainClass.fun(int, string, double, string, int)' has some invalid arguments // Argument `#2' cannot convert `int' expression to type `string' //fun( 123, 735, def2:-2, arg2:"wat?"); } } ============================== fun( 789, world, one, 456 ) fun( 123, world, hello, 2 ) fun( 123, hello, one, 456 ) fun( 123, hello, world, 2 )
 defaulted args = args that have default value
totally: - named args follows by unnamed args, not vice versa - unnamed args correspond to order of args in func-DEF. any of unnamed arg can be non-defaulted or defaulted arg in func-DEF. (as now) - named arg must not be specified again if its already set as unnamed. - u cannot skip defaulted args in unnamed list (as now) [what is not prohibited is allowed]: any defaulted args can be skipped when named list has begun
Aug 23
parent reply a11e99z <black80 bk.ru> writes:
On Friday, 23 August 2019 at 19:21:48 UTC, a11e99z wrote:
 On Friday, 23 August 2019 at 17:59:38 UTC, Andrei Alexandrescu 
 wrote:
 On 8/23/19 1:42 PM, H. S. Teoh wrote:
 On Fri, Aug 23, 2019 at 05:16:16PM +0000, bachmeier via 
 Digitalmars-d wrote:
 On Friday, 23 August 2019 at 16:47:14 UTC, H. S. Teoh wrote:
 - named arg must not be specified again if its already set as 
 unnamed.
CE error for this case is: Named argument 'name' specified multiple times.
Aug 23
parent a11e99z <black80 bk.ru> writes:
On Friday, 23 August 2019 at 19:25:17 UTC, a11e99z wrote:
 On Friday, 23 August 2019 at 19:21:48 UTC, a11e99z wrote:
 On Friday, 23 August 2019 at 17:59:38 UTC, Andrei Alexandrescu 
 wrote:
 On 8/23/19 1:42 PM, H. S. Teoh wrote:
 On Fri, Aug 23, 2019 at 05:16:16PM +0000, bachmeier via 
 Digitalmars-d wrote:
 On Friday, 23 August 2019 at 16:47:14 UTC, H. S. Teoh wrote:
 - named arg must not be specified again if its already set as 
 unnamed.
CE error for this case is: Named argument 'name' specified multiple times.
*C# and of course to:
 named arg must not be specified again if its already set as 
 unnamed.
- named arg should be specified once only
Aug 23
prev sibling parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
On Friday, 23 August 2019 at 17:59:38 UTC, Andrei Alexandrescu 
wrote:
 On 8/23/19 1:42 PM, H. S. Teoh wrote:
 On Fri, Aug 23, 2019 at 05:16:16PM +0000, bachmeier via 
 Digitalmars-d 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);
Exactly. It seems that for short lists (2-3 arguments) naming would be a net negative (add notational overhead when there's little possibility of a confusion to start with).
You don't have to add the names, it's not mandatory.
 Then, when the list gets longer it actually makes matters 
 _worse_ because it disallows skipping of defaulted arguments.
What do you mean by "worse". It's not currently possible to skip default arguments anyways. There is no way for incorporating this DIP to be a negative.
Aug 23
parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
So, again, there are a lot of suggestions that we need 
reordering, default arguments skipping, etc. And I completely 
agree. If someone come forward and write a well thought out named 
argument DIP with those features, I would happily drop mine.

However, during the 6 months long review of this (and DIP 1020, 
but that one is in hiatus right now), no one did. People cares a 
lot about these features, but not enough to write a DIP.

This is my biggest fear, that if we don't adapt this DIP and 
start iterate on that, D will not have named arguments for the 
foreseeable future.

Please prove me wrong. Go write a DIP.
Aug 23
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 24/08/2019 11:35 AM, Yuxuan Shui wrote:
 So, again, there are a lot of suggestions that we need reordering, 
 default arguments skipping, etc. And I completely agree. If someone come 
 forward and write a well thought out named argument DIP with those 
 features, I would happily drop mine.
 
 However, during the 6 months long review of this (and DIP 1020, but that 
 one is in hiatus right now), no one did. People cares a lot about these 
 features, but not enough to write a DIP.
DIP1020 is not on hiatus. The editing is almost done.
Aug 23
prev sibling parent reply bachmeier <no spam.net> writes:
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. The answer to that is to start currying function arguments or write a customized function that calls foo while holding fixed certain parameters. It's extremely clear when you change a single parameter in a struct. And nobody had to learn yet another piece of syntax in order to read D code. The best anyone can say is that this is not harmful in simple cases.
Aug 23
parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
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? Personally I think the FooParams version is more verbose and harder to read. Also the FooParams version forces default values on all parameters so when you forgot to specify one of the parameters, you won't get an error, which I consider to be very bad. Also, you don't have to write the names if you don't want to.
 The answer to that is to start currying function arguments or 
 write a customized function that calls foo while holding fixed 
 certain parameters. It's extremely clear when you change a 
 single parameter in a struct. And nobody had to learn yet 
 another piece of syntax in order to read D code. The best 
 anyone can say is that this is not harmful in simple cases.
This syntax is so simple that I think it's definitely worthwhile
Aug 23
parent reply bachmeier <no spam.net> writes:
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.
Aug 24
parent Ethan <gooberman gmail.com> writes:
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.
Aug 24
prev sibling next sibling parent Dmitry <dmitry indiedev.ru> writes:
On Friday, 23 August 2019 at 16:47:14 UTC, H. S. Teoh wrote:
 two of the most important reasons to *have* named arguments: 
 skipping default parameters, and out-of-order argument passing. 
  Therefore, it essentially nullifies its own raison d'etre.
+1 The things that I most expect from named arguments.
Aug 23
prev sibling next sibling parent Dennis <dkorpel gmail.com> writes:
On Friday, 23 August 2019 at 16:47:14 UTC, H. S. Teoh wrote:
 But this DIP neither enables nor disables inordinately long 
 parameter lists: the language already allows them!
It allows them, but it doesn't encourage them. Long parameter lists are currently rare in D as they should be.
 The only thing worse than an overly-long parameter list is one 
 in which you cannot (easily) tell which argument corresponds 
 with which parameter, and that's something this DIP would fix 
 (by letting you name the arguments so that they are 
 self-documenting).  So your argument doesn't really detract 
 from this DIP.
If you look at some of the longest parameter lists on Dub: https://github.com/jmh530/libnlopt/blob/06996b5c415cee2d2edd4efdeec078182fa24879/source/libnlopt/api.d#L300 https://github.com/d-widget-toolkit/dwt/blob/fa6b22597901a21fe51f91fb9628460fc71641fd/org.eclipse.swt.gtk.linux.x86/src/org/eclipse/swt/graphics/ImageData.d#L1794 https://github.com/Vild/xcb-d/blob/79e977943b187152924015bea090ee832ae92ef9/source/xcb/xkb.d#L5022 https://github.com/libmir/lapack/blob/1f00f70a15cdf10ba7564eff7e53dac3d070bd56/source/lapack/lapack.d#L651 My first observation is they are courtesy of other languages and not original D functions. Secondly, I don't think "if only we could use named parameters with default values, then these functions would be great.".
Aug 23
prev sibling parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
On Friday, 23 August 2019 at 16:47:14 UTC, H. S. Teoh wrote:
 On Fri, Aug 23, 2019 at 04:19:51PM +0000, Dennis via 
 Digitalmars-d wrote:
 [...]
Exactly the same objections I have against this DIP. OT1H it's trying to get named arguments into the language, but OTOH it takes out what I would consider to be two of the most important reasons to *have* named arguments: skipping default parameters, and out-of-order argument passing. Therefore, it essentially nullifies its own raison d'etre.
It DOES NOT prevent them from being added later. Like I have already reiterated multiple times, this is not the be-all and end-all named arguments DIP.
 [...]
[...] [...] Furthermore, if this DIP hadn't shot itself in its own foot by not allowing out-of-order argument passing and skipping default parameters, then it would have actually made overly-long parameter lists actually *acceptable*, in the sense that the function could just supply default values for most of the parameters, and the caller can just name and pass the few arguments that it wants to be different from the defaults, and the rest don't have to be explicitly specified.
It does not always make sense to supply default values for parameters. e.g createWindow(int width, int height) What default value do you give them?
 T
Aug 23
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Aug 23, 2019 at 11:41:21PM +0000, Yuxuan Shui via Digitalmars-d wrote:
 On Friday, 23 August 2019 at 16:47:14 UTC, H. S. Teoh wrote:
[...]
 Exactly the same objections I have against this DIP.  OT1H it's
 trying to get named arguments into the language, but OTOH it takes
 out what I would consider to be two of the most important reasons to
 *have* named arguments: skipping default parameters, and
 out-of-order argument passing.  Therefore, it essentially nullifies
 its own raison d'etre.
It DOES NOT prevent them from being added later. Like I have already reiterated multiple times, this is not the be-all and end-all named arguments DIP.
And that's exactly the problem: this DIP wants to introduce named arguments, but proposes a subset of functionality so weak that doesn't even offer what I consider to be two *major* advantages of having named arguments. Which begs the question, why even bother? Why not just take us all the way there and do a full DIP of the "be-all and end-all" of named arguments? [...]
 Furthermore, if this DIP hadn't shot itself in its own foot by not
 allowing out-of-order argument passing and skipping default
 parameters, then it would have actually made overly-long parameter
 lists actually *acceptable*, in the sense that the function could
 just supply default values for most of the parameters, and the
 caller can just name and pass the few arguments that it wants to be
 different from the defaults, and the rest don't have to be
 explicitly specified.
It does not always make sense to supply default values for parameters. e.g createWindow(int width, int height) What default value do you give them?
[...] Then don't give them any defaults. What makes you think you have to? T -- Without geometry, life would be pointless. -- VS
Aug 23
prev sibling parent Exil <Exil gmall.com> writes:
 Furthermore, if this DIP hadn't shot itself in its own foot by 
 not allowing out-of-order argument passing and skipping 
 default parameters, then it would have actually made 
 overly-long parameter lists actually *acceptable*, in the 
 sense that the function could just supply default values for 
 most of the parameters, and the caller can just name and pass 
 the few arguments that it wants to be different from the 
 defaults, and the rest don't have to be explicitly specified.
It does not always make sense to supply default values for parameters. e.g createWindow(int width, int height) What default value do you give them?
See this quite often. Usually values of -1 are used to auto calculate based on the contents of the window. There are a lot of instances default values are used. Named parameters are one of the few tools to use to keep those default values if you only want to modify one of them and there's multiple default value parameters.
Aug 23
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 8/23/19 12:19 PM, Dennis wrote:
 On Friday, 23 August 2019 at 15:01:20 UTC, Andrei Alexandrescu wrote:
 Large parameter lists of which most have reasonable defaults is a 
 marquee use case of named arguments. A proposal that works itself out 
 of that opportunity cannot and should not be acceptable.
I'm personally not a fan of those argument lists the size of the Magna Cartas like you see in Python libraries: https://matplotlib.org/3.1.1/api/_as_gen/matplotlib.lines.Line2D.html#mat lotlib.lines.Line2D
Abuse is a possibility.
 In many cases (like the recent scope/ safe related proposals) I agree 
 that implementing only part of a design has little value, but in this 
 case the proposal has merits even in this limited form. Take for example 
 this line:
 
 glfwCreateWindow(1280, 720, "my window", null, null);
 
 You can easily guess what the first three arguments are, but what about 
 those two nulls? It could be made clearer like this:
 
 glfwCreateWindow(1280, 720, "my window", fullScreenMonitor: null, 
 parentWindow: null);
 
 You can't leave `fullScreenMonitor` to the default while passing 
 `parentWindow` with this DIP, but writing out that argument doesn't seem 
 like a big loss to me. And even if it is, limitations can easily be 
 lifted without much friction. If it turns out that reordering causes 
 problems down the line, deprecating them would be more of a hassle.
Funny you should mention this, because the obvious problem is this doesn't work: glfwCreateWindow(1280, 720, "my window", parentWindow: null, fullScreenMonitor: null);
Aug 23
parent Dennis <dkorpel gmail.com> writes:
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.
Aug 24
prev sibling next sibling parent reply JN <666total wp.pl> writes:
On Friday, 23 August 2019 at 16:19:51 UTC, Dennis wrote:
 You can't leave `fullScreenMonitor` to the default while 
 passing `parentWindow` with this DIP, but writing out that 
 argument doesn't seem like a big loss to me. And even if it is, 
 limitations can easily be lifted without much friction. If it 
 turns out that reordering causes problems down the line, 
 deprecating them would be more of a hassle.
It is a loss. It's basically the same situation as the thing people were bringing up - named arguments allow you to detect a case when arguments get renamed and semantics change, rect(x, y, width, height) vs rect(x1, y1, x2, y2). But this is almost the same case, except you are binding yourself to the default value for fullScreenMonitor to null. You want to do the default here. What if the default gets changed and fullScreenMonitor is supposed to be fooMonitor instead? You can get silent breakages because you're overriding the default behavior now. I like the idea of this DIP. I think skipping over default parameters should be a thing.
Aug 23
parent Dennis <dkorpel gmail.com> writes:
On Friday, 23 August 2019 at 19:01:35 UTC, JN wrote:
 named arguments allow you to detect a case when arguments get 
 renamed and semantics change, rect(x, y, width, height) vs 
 rect(x1, y1, x2, y2).  (...)
 What if the default gets changed and fullScreenMonitor is 
 supposed to be fooMonitor instead?
If they did something like that tens of thousands of C projects would break. For that reason they'd never simply overhaul function semantics while remaining the same function prototype. It strikes me that people consider this an actual real-world scenario, but maybe I'm missing something. Did this ever happen to a library?
Aug 23
prev sibling next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, August 23, 2019 10:47:14 AM MDT H. S. Teoh via Digitalmars-d 
wrote:
 On Fri, Aug 23, 2019 at 04:19:51PM +0000, Dennis via Digitalmars-d wrote:
 On Friday, 23 August 2019 at 15:01:20 UTC, Andrei Alexandrescu wrote:
 Large parameter lists of which most have reasonable defaults is a
 marquee use case of named arguments. A proposal that works itself
 out of that opportunity cannot and should not be acceptable.
Exactly the same objections I have against this DIP. OT1H it's trying to get named arguments into the language, but OTOH it takes out what I would consider to be two of the most important reasons to *have* named arguments: skipping default parameters, and out-of-order argument passing. Therefore, it essentially nullifies its own raison d'etre.
 I'm personally not a fan of those argument lists the size of the Magna
 Cartas like you see in Python libraries:
 https://matplotlib.org/3.1.1/api/_as_gen/matplotlib.lines.Line2D.html#ma
 tplotlib.lines.Line2D I don't see it as a loss that this DIP doesn't
 enable those in D. If your function takes more than 6 arguments you
 should really consider creating a struct with configuration data.
[...] But this DIP neither enables nor disables inordinately long parameter lists: the language already allows them! The only thing worse than an overly-long parameter list is one in which you cannot (easily) tell which argument corresponds with which parameter, and that's something this DIP would fix (by letting you name the arguments so that they are self-documenting). So your argument doesn't really detract from this DIP. Furthermore, if this DIP hadn't shot itself in its own foot by not allowing out-of-order argument passing and skipping default parameters, then it would have actually made overly-long parameter lists actually *acceptable*, in the sense that the function could just supply default values for most of the parameters, and the caller can just name and pass the few arguments that it wants to be different from the defaults, and the rest don't have to be explicitly specified.
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. 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. Such functions are usually a bad design, so I'm fine with not having named arguments in the language to make such designs seem more reasonable. If your parameter list is long enough that it doesn't work to go by the order of the arguments, then you already have a problem. But if we're going to add named arguments, then IMHO, the rare case where it actually makes sense to have a lot of parameters with default arguments is what named arguments are there to solve. So, if the DIP can't solve that, then IMHO, it's just making the language worse to no benefit. - Jonathan M Davis
Aug 23
next sibling parent reply Kagamin <spam here.lot> writes:
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.
Aug 26
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, August 26, 2019 8:18:21 AM MDT Kagamin via Digitalmars-d wrote:
 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.
My point is that adding named arguments results in even more bikeshedding over names. We already have more than enough trouble with that over function names and type names in APIs. I don't want parameter names to be added to that. I don't want to have to care about how good the parameter names are or have to worry about breaking anyone's code when changing a parameter name. And since parameter names have never actually been part of the API in D, existing parameter names were not selected with the idea that they would be used by anyone other than the function itself. For instance, if we had named arguments, all of a sudden, we'd have issues with whether range-based used range, r, or some other name entirely for the range that they're consuming or wrapping. Phobos is not at all consistent about that - and it hasn't needed to be. If we added named arguments, that sort of thing would then matter. I don't want to have to deal with any of that.
 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.
Honestly, I don't think that Flag is worth much. In most cases, a simple bool would do the job just fine. You already have to know what the parameter is for to use the function anyway. In general, it seems to me like Flag is an excuse for people to think that they don't need to actually read the documentation. And the cases where you really get value out of an enum are generally the cases where you need more than just true and false. I know that some folks like Flag, but in general, I think that it's an unnecessary complication. - Jonathan M Davis
Aug 26
next sibling parent reply Ethan <gooberman gmail.com> writes:
On Monday, 26 August 2019 at 21:48:42 UTC, Jonathan M Davis wrote:
 I know that some folks like Flag, but in general, I think that 
 it's an unnecessary complication.
I'm all about information at a glance. The more you are able to understand a line of code without looking at the surrounding lines, the clearer and easier to maintain that code is. Simple example: void DoSomething( bool Multithreaded, bool Logging ); Which, when invoked using literals, looks like: DoSomething( true, false ); Yech. That's where flags comes in handy: DoSomething( Multithreaded.Yes, Logging.No ); Bam. Far more readable at a glance. Named parameters remove the template instantiations from that example: DoSomething( Multithreaded : true, Logging : false ); At the cost of needing to do a "find and replace in files" when upgrading compilers/libraries if a parameter name changes, in both cases you have far more readable code. Besides. Didn't the DIP here include a mechanism for handling parameter renaming and forwarding? And marking parameter name sets as deprecated?
Aug 26
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, August 26, 2019 4:18:51 PM MDT Ethan via Digitalmars-d wrote:
 On Monday, 26 August 2019 at 21:48:42 UTC, Jonathan M Davis wrote:
 I know that some folks like Flag, but in general, I think that
 it's an unnecessary complication.
I'm all about information at a glance. The more you are able to understand a line of code without looking at the surrounding lines, the clearer and easier to maintain that code is. Simple example: void DoSomething( bool Multithreaded, bool Logging ); Which, when invoked using literals, looks like: DoSomething( true, false ); Yech. That's where flags comes in handy: DoSomething( Multithreaded.Yes, Logging.No ); Bam. Far more readable at a glance. Named parameters remove the template instantiations from that example: DoSomething( Multithreaded : true, Logging : false ); At the cost of needing to do a "find and replace in files" when upgrading compilers/libraries if a parameter name changes, in both cases you have far more readable code.
That particular use of Flag is more valuable than many uses of it, because you actually have multiple arguments, whereas in most cases, only one Flag gets used. Ultimately though, unless there are a lot of parameters (which is usually bad function design), I think that the benifit is minimal. I get the impression that many people just want to use Flag or named arguments as an excuse to avoid even reading the function's documentation. I agree that it's great if what a function call does is obvious at a glance, but I also think that it's dangerous to assume that you know just by looking at the function call. If you don't actually read the function's documentation, then it's easy to end up making bad assumptions about what it does. Naming is important and having the function's name be representative of what it does makes it far easier to remember what it's supposed to do, and it does help see what code probably does at a glance when you haven't read the docs yet, but ultimately, you need to read the docs, and when people argue for named arguments, it frequently seems like they want to be able to just look at a piece of code and know exactly what it does without ever reading the docs (heck, many people seem to want that based purely off of how a function is named, which is part of why there's a ton of bikeshedding over function names). Once you've actually read the docs and are familiar with what the functions do, then the names serve to remind you rather than inform you, and the need to label everything is far less. But for a lot of arguments, you have the names of the variables being passed anyway, and if anyone really wants to label what a boolean literal is for, they can always use a comment in-place.
 Besides. Didn't the DIP here include a mechanism for handling
 parameter renaming and forwarding? And marking parameter name
 sets as deprecated?
That doesn't change the fact that the parameter names are then part of the API and are yet another set of names that are going to be the subject of bikeshedding and are going to be something that you then can't simply change without worrying about breaking code. Having a way to deprecate names makes it possible to change stuff over time, but it's still far better IMHO to not have the names be part of the API in the first place. For me personally, I think that having to deal with parameters becoming part of the API and how that adds to the difficulties that already exist around naming functions and types in public APIs is enough of a problem that it outweighs any of the supposed benefits that named arguments provide - even more so when it frequently seems like the reasons behind wanting named arguments relate to making badly designed functions easier to deal with (e.g. having tons of parameters for a function) or relate to folks looking to avoid reading documentation. - Jonathan M Davis
Aug 26
next sibling parent Olivier FAURE <couteaubleu gmail.com> writes:
On Monday, 26 August 2019 at 23:36:22 UTC, Jonathan M Davis wrote:
 I get the impression that many people just want to use Flag or 
 named arguments as an excuse to avoid even reading the 
 function's documentation. I agree that it's great if what a 
 function call does is obvious at a glance, but I also think 
 that it's dangerous to assume that you know just by looking at 
 the function call. If you don't actually read the function's 
 documentation, then it's easy to end up making bad assumptions 
 about what it does.

 Naming is important and having the function's name be 
 representative of what it does makes it far easier to remember 
 what it's supposed to do, and it does help see what code 
 probably does at a glance when you haven't read the docs yet, 
 but ultimately, you need to read the docs, [...] Once you've 
 actually read the docs and are familiar with what the functions 
 do, then the names serve to remind you rather than inform you, 
 and the need to label everything is far less. But for a lot of 
 arguments, you have the names of the variables being passed 
 anyway, and if anyone really wants to label what a boolean 
 literal is for, they can always use a comment in-place.
I'm mostly neutral on named parameters (they're nice to have), but I'm not sure I agree with the reasoning here. In theory, it would be nice to always refer to documentation before using a function. In practice, in most of my jobs so far, I have almost never done so except when working with an external library, for good reasons: - I don't want to use an IDE (Atom's multi-cursor support is a core part of my workflow, among other things), which means I don't have documentation-as-hover-text yet. - I'm often asked to make a 2-lines change in a 60-lines function, and reading the documentation for each function call is simply not an efficient way to do that. I need to be able to locate the parts relevant to my task quickly, and informative names help me *a lot*. - For most of the code I work on, the documentation looks like this: /** *** This method is used to set visible or invisible the HopPoints. **/ void makeHopPointVisible(bool i_hopPointVisible); eg, it paraphrases what the prototype already says. Now, documentation is important and valuable, and I do read it when I'm eg rewriting a function. But having code that can be understood at a glance without looking at its source/doc is also valuable, and I think this value far outweighs the moral hazard of occasional bikeshedding or of people skipping documentation. (the above goes triple for developers with accessibility issues, eg blind devs using text-to-speech to browse code)
Aug 27
prev sibling parent Ethan <gooberman gmail.com> writes:
On Monday, 26 August 2019 at 23:36:22 UTC, Jonathan M Davis wrote:
 That particular use of Flag is more valuable than many uses of 
 it, because you actually have multiple arguments
It's exactly as valuable as single arguments. For example: DoSomething( Multithreaded.Yes ); DoSomething( Mutlithreaded : true ); Versus: DoSomething( true ); Or even worse: enum bool IsMultithreaded = true; DoSomething( IsMultithreaded ); (Two lines of code need to be understood for a single function call; and there's no guarantee that the IsMultithreaded parameter is defined next to the call site. For anyone choosing to single that one out, there's your answers.) Did you know it's a coding standard at Insomniac - creators of Ratchet and Clank and the recent Spiderman game - to not use boolean arguments and instead create one of those yes/no enums? I've already stated that named arguments as a language feature are not a method of enforcing programming standards on people. How you choose to approach the above problem is up to the programmer. If they want to aim for readable like my examples, great. If they want to aim for obtuse interfaces that requires understanding pages of documentation, well, that's up to them too. Certainly, all this talk about documentation falls within the "programming standards" point I raise.
Aug 27
prev sibling parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
On Monday, 26 August 2019 at 21:48:42 UTC, Jonathan M Davis wrote:
 On Monday, August 26, 2019 8:18:21 AM MDT Kagamin via 
 Digitalmars-d wrote:
 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.
My point is that adding named arguments results in even more bikeshedding over names. We already have more than enough trouble with that over function names and type names in APIs. I don't want parameter names to be added to that. I don't want to have to care about how good the parameter names are or have to worry about breaking anyone's code when changing a parameter name. And since parameter names have never actually been part of the API in D, existing parameter names were not selected with the idea that they would be used by anyone other than the function itself. For instance, if we had named arguments, all of a sudden, we'd have issues with whether range-based used range, r, or some other name entirely for the range that they're consuming or wrapping. Phobos is not at all consistent about that - and it hasn't needed to be. If we added named arguments, that sort of thing would then matter. I don't want to have to deal with any of that.
I agree this _could_ be a problem. In fact, if you were there during the first community review, you would know I anticipated this objection, by adding the named attribute. But, OTOH, there are quite a lot of languages supporting named arguments, and I don't think I ever heard this become a problem for them. So, yes, theoretically this is a problem; in practice, not so much?
 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.
Disagree. Oftentimes having the name clarifies a function, so the _reader_ doesn't have to read the document to figure out what a function call does (e.g. // width first, or height first? createWindow(100, 200); // ah createWindow(height: 100, width: 200); ) Remember, code is not written just for the compiler to ingest.
 - Jonathan M Davis
Aug 27
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Aug 27, 2019 at 05:01:21PM +0000, Yuxuan Shui via Digitalmars-d wrote:
 On Monday, 26 August 2019 at 21:48:42 UTC, Jonathan M Davis wrote:
[...]
 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.
Disagree. Oftentimes having the name clarifies a function, so the _reader_ doesn't have to read the document to figure out what a function call does
[...] That's exactly Jonathan's point. The reader *assumes* semantics based on the names of the function and parameters. But without actually reading the documentation, you cannot know for sure. And I think by now we all know what happens when we make assumptions about a function that we don't actually understand. So the point is that if you want to understand what the code actually does, you have to read the docs. Having named arguments doesn't relieve you of that need. I can't say I 100% agree with Jonathan, but he certainly has a point that you can't avoid reading documentation at *some* point. T -- First Rule of History: History doesn't repeat itself -- historians merely repeat each other.
Aug 27
next sibling parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
On Tuesday, 27 August 2019 at 17:39:44 UTC, H. S. Teoh wrote:
 On Tue, Aug 27, 2019 at 05:01:21PM +0000, Yuxuan Shui via 
 Digitalmars-d wrote:
 On Monday, 26 August 2019 at 21:48:42 UTC, Jonathan M Davis 
 wrote:
[...]
 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.
Disagree. Oftentimes having the name clarifies a function, so the _reader_ doesn't have to read the document to figure out what a function call does
[...] That's exactly Jonathan's point. The reader *assumes* semantics based on the names of the function and parameters.
Well at this point you might just as well say the reader cannot *assume* semantics based on the documentation of the function either.
Aug 27
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, August 27, 2019 12:05:25 PM MDT Yuxuan Shui via Digitalmars-d 
wrote:
 On Tuesday, 27 August 2019 at 17:39:44 UTC, H. S. Teoh wrote:
 On Tue, Aug 27, 2019 at 05:01:21PM +0000, Yuxuan Shui via

 Digitalmars-d wrote:
 On Monday, 26 August 2019 at 21:48:42 UTC, Jonathan M Davis
 wrote:
[...]
 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.
Disagree. Oftentimes having the name clarifies a function, so the _reader_ doesn't have to read the document to figure out what a function call does
[...] That's exactly Jonathan's point. The reader *assumes* semantics based on the names of the function and parameters.
Well at this point you might just as well say the reader cannot *assume* semantics based on the documentation of the function either.
There's a world of difference between assuming that what the documentation says is correct and assuming that you understand what a function does correctly based off of its name (and potentially the name of its parameters if named arguments are used). The name of a function should be representative of what it does and make it easier to remember what the function does after you've already read the documentation (the same would be true of parameters if named arguments are in the language), but ultimately, anyone using a function needs to read its documentation rather than assuming what it does based on its name or the name of its arguments. In worse cases, you do have to actually go read the function's source to know what it does, but that just means that the documentation was bad or nonexistent, which is of course undesirable and shouldn't happen (especially in publicly available libraries). We do all unfortunately sometimes have to deal with such situations, but regardless, it's not reasonable to assume what a function does based solely on its name, the name of its parameters, or the names of its arguments. If that's supposed to be one of the main benefits of named arguments, then I think that that's a great reason _not_ to have them. This sort of issue seems to come up at least some of the time when naming functions or types. Some people seem to think that they should be able to just think of a name and have it exist and act exactly the way they want without looking anything up. Similarly, some people tend to think that when they see a name, they should know exactly what it does based on the name and how it was used without reading the docs. None of that is reasonable IMHO. You always need to read the documentation, because it's frequently the case that a function doesn't work exactly the way you infer that it does, and unless the person who named the function thinks exactly like you do, differences in names and behaviors are bound to pop up. Ultimately, good names help people remember what stuff does (and even help them infer what things probably do before actually reading the docs), but there is no excuse for not reading the documentation (beyond it not existing, in which case, that's on the head of whoever wrote it, and you're potentially going to have to read the source code to get the information you need, which is a whole other problem). - Jonathan M Davis
Aug 27
parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
On Tuesday, 27 August 2019 at 20:27:13 UTC, Jonathan M Davis 
wrote:
 On Tuesday, August 27, 2019 12:05:25 PM MDT Yuxuan Shui via 
 Digitalmars-d wrote:
 On Tuesday, 27 August 2019 at 17:39:44 UTC, H. S. Teoh wrote:
 On Tue, Aug 27, 2019 at 05:01:21PM +0000, Yuxuan Shui via

 Digitalmars-d wrote:
 On Monday, 26 August 2019 at 21:48:42 UTC, Jonathan M Davis
 wrote:
[...]
 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.
Disagree. Oftentimes having the name clarifies a function, so the _reader_ doesn't have to read the document to figure out what a function call does
[...] That's exactly Jonathan's point. The reader *assumes* semantics based on the names of the function and parameters.
Well at this point you might just as well say the reader cannot *assume* semantics based on the documentation of the function either.
There's a world of difference between assuming that what the documentation says is correct and assuming that you understand what a function does correctly based off of its name (and potentially the name of its parameters if named arguments are used). The name of a function should be representative of what it does and make it easier to remember what the function does after you've already read the documentation (the same would be true of parameters if named arguments are in the language), but ultimately, anyone using a function needs to read its documentation rather than assuming what it does based on its name or the name of its arguments. In worse cases, you do have to actually go read the function's source to know what it does, but that just means that the documentation was bad or nonexistent, which is of course undesirable and shouldn't happen (especially in publicly available libraries). We do all unfortunately sometimes have to deal with such situations, but regardless, it's not reasonable to assume what a function does based solely on its name, the name of its parameters, or the names of its arguments. If that's supposed to be one of the main benefits of named arguments, then I think that that's a great reason _not_ to have them. This sort of issue seems to come up at least some of the time when naming functions or types. Some people seem to think that they should be able to just think of a name and have it exist and act exactly the way they want without looking anything up. Similarly, some people tend to think that when they see a name, they should know exactly what it does based on the name and how it was used without reading the docs. None of that is reasonable IMHO. You always need to read the documentation, because it's frequently the case that a function doesn't work exactly the way you infer that it does, and unless the person who named the function thinks exactly like you do, differences in names and behaviors are bound to pop up. Ultimately, good names help people remember what stuff does (and even help them infer what things probably do before actually reading the docs), but there is no excuse for not reading the documentation (beyond it not existing, in which case, that's on the head of whoever wrote it, and you're potentially going to have to read the source code to get the information you need, which is a whole other problem).
I am not saying having argument names can completely eliminate the need to read the documents. But there are cases where the function name and parameter names so obviously indicates what the function does (e.g. createWindow(height: , width: )), if the function actually does something else, it would mean it was written terribly. And there are also cases where you have read the document of the function, know what the function does, but cannot remember exactly what each of the parameters are for. Having the name of the parameters could help tremendously.
 - Jonathan M Davis
Aug 28
parent reply Andre Pany <andre s-e-a-p.de> writes:
On Wednesday, 28 August 2019 at 10:40:14 UTC, Yuxuan Shui wrote:
 On Tuesday, 27 August 2019 at 20:27:13 UTC, Jonathan M Davis 
 wrote:
 [...]
I am not saying having argument names can completely eliminate the need to read the documents. But there are cases where the function name and parameter names so obviously indicates what the function does (e.g. createWindow(height: , width: )), if the function actually does something else, it would mean it was written terribly. And there are also cases where you have read the document of the function, know what the function does, but cannot remember exactly what each of the parameters are for. Having the name of the parameters could help tremendously.
 [...]
IntelliJ IDEA has a functionality to show parameter names in source code: https://www.jetbrains.com/help/rider/Inline_Parameter_Name_Hints.html This functionality does what the current goal of the DIP is. Unfortunately it isn't currently implemented in the D plugin for Intellij. Kind regards Andre
Aug 28
next sibling parent reply IGotD- <nise nise.com> writes:
On Wednesday, 28 August 2019 at 12:44:45 UTC, Andre Pany wrote:
 IntelliJ IDEA has a functionality to show parameter names in 
 source code:

 https://www.jetbrains.com/help/rider/Inline_Parameter_Name_Hints.html

 This functionality does what the current goal of the DIP is.

 Unfortunately it isn't currently implemented in the D plugin 
 for Intellij.


 Kind regards
 Andre
Many editors let you right click to an option that takes you to the declaration of the function that you use. Maybe not as supported with D as with C/C++ though. The only reason for the named arguments are optional arguments as I see it.
Aug 28
parent reply Andre Pany <andre s-e-a-p.de> writes:
On Wednesday, 28 August 2019 at 16:23:32 UTC, IGotD- wrote:
 On Wednesday, 28 August 2019 at 12:44:45 UTC, Andre Pany wrote:
 IntelliJ IDEA has a functionality to show parameter names in 
 source code:

 https://www.jetbrains.com/help/rider/Inline_Parameter_Name_Hints.html

 This functionality does what the current goal of the DIP is.

 Unfortunately it isn't currently implemented in the D plugin 
 for Intellij.


 Kind regards
 Andre
Many editors let you right click to an option that takes you to the declaration of the function that you use. Maybe not as supported with D as with C/C++ though. The only reason for the named arguments are optional arguments as I see it.
From your answer I am not sure you misunderstood the functionality. The source code is enhanced with the parameter names while reading the source code. You do not have to click anything. Please see the example from the link. Kind regards Andre
Aug 28
parent IGotD- <nise nise.com> writes:
On Wednesday, 28 August 2019 at 17:06:10 UTC, Andre Pany wrote:
 From your answer I am not sure you misunderstood the 
 functionality. The source code is enhanced with the parameter 
 names while reading the source code. You do not have to click 
 anything.
 Please see the example from the link.

 Kind regards
 Andre
Yes, I've seen it. Not really my cup of tea as I think it clutters the code. However, this is an editor option that you can turn off. Basically, we can get help from the IDE tool rather than support from the language for the purpose of clarity.
Aug 28
prev sibling parent reply JN <666total wp.pl> writes:
On Wednesday, 28 August 2019 at 12:44:45 UTC, Andre Pany wrote:
 IntelliJ IDEA has a functionality to show parameter names in 
 source code:

 https://www.jetbrains.com/help/rider/Inline_Parameter_Name_Hints.html

 This functionality does what the current goal of the DIP is.

 Unfortunately it isn't currently implemented in the D plugin 
 for Intellij.


 Kind regards
 Andre
It does one part of the functionality, which is making function calls clearer. But so can every IDE tell you the args. Likewise, when opening a ( in function call in an IDE, they often show "ghost" argument names that you can fill in the gaps. But these IDE features don't solve the "long parameter list with most being optional" (kinda like Builder pattern) thing, which this DIP also resolves.
Aug 30
parent matheus <matheus gmail.com> writes:
On Friday, 30 August 2019 at 08:35:10 UTC, JN wrote:
 But these IDE features don't solve the "long parameter list 
 with most being optional" (kinda like Builder pattern) thing, 
 which this DIP also resolves.
But you could write a plugin to handle this based on the language specs, and show to the user through the IDE. Matheus.
Aug 30
prev sibling parent Dukc <ajieskola gmail.com> writes:
On Tuesday, 27 August 2019 at 17:39:44 UTC, H. S. Teoh wrote:
 That's exactly Jonathan's point.  The reader *assumes* 
 semantics based on the names of the function and parameters.  
 But without actually reading the documentation, you cannot know 
 for sure.  And I think by now we all know what happens when we 
 make assumptions about a function that we don't actually 
 understand.  So the point is that if you want to understand 
 what the code actually does, you have to read the docs. Having 
 named arguments doesn't relieve you of that need.

 I can't say I 100% agree with Jonathan, but he certainly has a 
 point that you can't avoid reading documentation at *some* 
 point.


 T
Named parameters are intended for when you remember partially, but not fully, the function you are calling. Yuxan provided a good example of such situation. Personally, I'd be unlikely to forget ordering of width and height, but if I was hunting a rendering bug and encountered `drawRect(100, 100, a[0], a[1], true)`, it's fairly likely I wouldn't remember whether the latter two parameters are absolute or relative to first two, and/or what that `true` stands for. I'd have to open the documentation, which tends to have the same effect on me as long compile times on some. Alternatively, I could open the file where `drawRect()` is defined and have Geany to hint me the parameter names, but that file could be deep in some DUB package, even slower to fire up than the docs. Assuming I wrote the call myself, parameter names would give my memory enough hint that I wouldn't have to bother with the doc.
Aug 27
prev sibling parent matheus <matheus gmail.com> writes:
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. 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. Such functions 
 are usually a bad design, so I'm fine with not having named 
 arguments in the language to make such designs seem more 
 reasonable. If your parameter list is long enough that it 
 doesn't work to go by the order of the arguments, then you 
 already have a problem. But if we're going to add named 
 arguments, then IMHO, the rare case where it actually makes 
 sense to have a lot of parameters with default arguments is 
 what named arguments are there to solve. So, if the DIP can't 
 solve that, then IMHO, it's just making the language worse to 
 no benefit.
+1. Matheus.
Aug 26
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Aug 23, 2019 at 07:09:48PM -0600, Jonathan M Davis via Digitalmars-d
wrote:
 [...] But if we're going to add named arguments, then IMHO, the rare
 case where it actually makes sense to have a lot of parameters with
 default arguments is what named arguments are there to solve. So, if
 the DIP can't solve that, then IMHO, it's just making the language
 worse to no benefit.
[...] Yeah, that's why I said, this DIP kinda nullifies its own raison d'etre. I withhold judgment on the value of named arguments in general, but at the very least, this DIP could have offered its primary benefits, which to me are (1) reordered arguments, and (2) skipping default arguments. Without these two primary benefits, it's hard for me to imagine how this DIP could pull its own weight. It's like promising to cook chicken pot pie, but when the dish arrives there's only pie and no chicken. Who would pay for that? T -- IBM = I'll Buy Microsoft!
Aug 23
parent reply Newbie2019 <newbie2019 gmail.com> writes:
On Saturday, 24 August 2019 at 01:26:48 UTC, H. S. Teoh wrote:
 Without these two primary benefits, it's hard for me to imagine 
 how this DIP could pull its own weight.  It's like promising to 
 cook chicken pot pie, but when the dish arrives there's only 
 pie and no chicken.  Who would pay for that?
I agree. Without reordered and skipping default, I consider in-place-inited struct is more useful then this DIP.
Aug 23
parent reply a11e99z <black80 bk.ru> writes:
On Saturday, 24 August 2019 at 01:43:31 UTC, Newbie2019 wrote:
 On Saturday, 24 August 2019 at 01:26:48 UTC, H. S. Teoh wrote:
 Without these two primary benefits, it's hard for me to 
 imagine how this DIP could pull its own weight.  It's like 
 promising to cook chicken pot pie, but when the dish arrives 
 there's only pie and no chicken.  Who would pay for that?
I agree. Without reordered and skipping default, I consider in-place-inited struct is more useful then this DIP.
struct is only one entity, so compiler knows what exactly initialized but function can be overloaded 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); }
Aug 23
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, August 23, 2019 11:00:06 PM MDT a11e99z via Digitalmars-d wrote:
 On Saturday, 24 August 2019 at 01:43:31 UTC, Newbie2019 wrote:
 On Saturday, 24 August 2019 at 01:26:48 UTC, H. S. Teoh wrote:
 Without these two primary benefits, it's hard for me to
 imagine how this DIP could pull its own weight.  It's like
 promising to cook chicken pot pie, but when the dish arrives
 there's only pie and no chicken.  Who would pay for that?
I agree. Without reordered and skipping default, I consider in-place-inited struct is more useful then this DIP.
struct is only one entity, so compiler knows what exactly initialized but function can be overloaded 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); }
The simple answer is to just make it illegal to mix named arguments with normal arguments. If you use a name with one of them, you have to use a name with all of them. - Jonathna M Davis
Aug 23
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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
Aug 23
next sibling parent a11e99z <black80 bk.ru> writes:
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.
Aug 24
prev sibling next sibling parent a11e99z <black80 bk.ru> writes:
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.
Aug 24
prev sibling parent a11e99z <black80 bk.ru> writes:
On Saturday, 24 August 2019 at 06:17:07 UTC, Walter Bright wrote:
 On 8/23/2019 10:00 PM, a11e99z wrote:
by the way can we use named arguments for struct literals or only for defined constructors? https://dlang.org/spec/struct.html#struct-literal
Aug 27
prev sibling parent Andre Pany <andre s-e-a-p.de> writes:
On Friday, 23 August 2019 at 15:01:20 UTC, Andrei Alexandrescu 
wrote:
 On 8/23/19 6: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.
 
 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.
The DIP is well researched and clearly written. Kudos. Sadly I oppose it on the following grounds: "Named arguments proposed by this DIP have no effect on the ordering of arguments in function calls." "Named arguments proposed by this DIP do not allow default parameters to be skipped." These two limitations are as useful and help each other as much as a nausea and a cough. Large parameter lists of which most have reasonable defaults is a marquee use case of named arguments. A proposal that works itself out of that opportunity cannot and should not be acceptable. I was unconvinced by the argument that these can be added later. Language design is peculiar in that incrementalism doesn't work well - it must come all at once. There are exceptions and arguments that can be made but there's overwhelming evidence that incremental language design is just not a good way to go about things.
To stress these points, IntelliJ IDEA has the possibility to show the function arguments name while reading source code (it isn't implemented for D). Other IDEs maybe provide something similar. What I want to say: The current scope of the DIP does only hard code what a good IDE is able to provide on the fly. I really miss the possibility to skip optional parameters. Kind regards Andre
Aug 23
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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
Aug 23
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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?
Aug 24
next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
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?
Aug 24
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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.
Aug 25
prev sibling next sibling parent Sebastiaan Koppe <mail skoppe.eu> writes:
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.
Aug 24
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
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.
Aug 24
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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.
Aug 25
prev sibling parent Atila Neves <atila.neves gmail.com> writes:
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.
Aug 26
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
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?
Aug 26
parent reply Kagamin <spam here.lot> writes:
And description of algorithm is unclear 
https://dlang.org/spec/struct.html#static_struct_init
Aug 26
parent reply Kagamin <spam here.lot> writes:
struct S { int a, b, c, d = 7; }
S w = { c:1, a:1, 3 };

I don't even know if this result is contrived. Maybe it's trivial?
Aug 26
next sibling parent Kagamin <spam here.lot> writes:
Formally: struct initializer syntax is very powerful and has only 
one restriction, but the consequence of this power is lack of 
redundancy with the usual consequences.
Aug 26
prev sibling next sibling parent a11e99z <black80 bk.ru> writes:
On Monday, 26 August 2019 at 14:47:01 UTC, Kagamin wrote:
 struct S { int a, b, c, d = 7; }
 S w = { c:1, a:1, 3 };

 I don't even know if this result is contrived. Maybe it's 
 trivial?
of course its trivial, this is "D Rorschach test". even more: u can get green care-De belt if u can answer how will be initialized struct just look at 20 samples. and u will get brown care-De belt when u can say same for overloaded functions. everything has already been decided. u can write like that, there won’t be any errors, just don’t write like that.
Aug 26
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/26/2019 7:47 AM, Kagamin wrote:
 struct S { int a, b, c, d = 7; }
 S w = { c:1, a:1, 3 };
 
 I don't even know if this result is contrived. Maybe it's trivial?
It initializes to: c = 1 a = 1 b = 3 d = 7
Aug 26
next sibling parent reply aliak <something something.com> writes:
On Monday, 26 August 2019 at 22:45:16 UTC, Walter Bright wrote:
 On 8/26/2019 7:47 AM, Kagamin wrote:
 struct S { int a, b, c, d = 7; }
 S w = { c:1, a:1, 3 };
 
 I don't even know if this result is contrived. Maybe it's 
 trivial?
It initializes to: c = 1 a = 1 b = 3 d = 7
So just to test out what people would say, I went around my team with this (individually, they didn't hear each other) struct S { int a = 1, b = 2, c = 3, d = 4; } void main() { S w = { d: 9, a: 9, 9 }; writeln(w); } The answers: 1. a 9, d: 9,... b...2? wait no .... what? Ok I don't know. 2. ambiguous? compile error! why would this be allowed? 3. does the last 9 set all the unset vars?? 4. Can't tell, but the first highest non set address? 5. compilation error 6. What is this. What is the usefulness of this. Nothing happens. It's bad. It should crash. I hate life. 7. this can't compile. If it does I would assume it's thrown away? 8. should crash? Please don't allow the same logic to go in to named arguments.
Aug 27
next sibling parent reply drug <drug2004 bk.ru> writes:
27.08.2019 16:47, aliak пишет:
 On Monday, 26 August 2019 at 22:45:16 UTC, Walter Bright wrote:
 
 So just to test out what people would say, I went around my team with 
 this (individually, they didn't hear each other)
 
 struct S { int a = 1, b = 2, c = 3, d = 4; }
 
 void main() {
      S w = { d: 9, a: 9, 9 };
      writeln(w);
 }
 
 The answers:
 
 1. a 9, d: 9,... b...2? wait no .... what? Ok I don't know.
 2. ambiguous? compile error! why would this be allowed?
 3. does the last 9 set all the unset vars??
 4. Can't tell, but the first highest non set address?
 5. compilation error
 6. What is this. What is the usefulness of this. Nothing happens. It's 
 bad. It should crash. I hate life.
 7. this can't compile. If it does I would assume it's thrown away?
 8. should crash?
 
 Please don't allow the same logic to go in to named arguments.
That is rather simple logic - named arguments are defined by name, unnamed ones are defined by position starting from the last named argument, i.e. the first unnamed argument follows the last named one.
Aug 27
parent Yuxuan Shui <yshuiv7 gmail.com> writes:
On Tuesday, 27 August 2019 at 13:52:19 UTC, drug wrote:
 27.08.2019 16:47, aliak пишет:
 [...]
That is rather simple logic - named arguments are defined by name, unnamed ones are defined by position starting from the last named argument, i.e. the first unnamed argument follows the last named one.
Correct, but simple logic-wise doesn't mean it's obvious, or intuitive.
Aug 27
prev sibling parent matheus <matheus gmail.com> writes:
On Tuesday, 27 August 2019 at 13:47:49 UTC, aliak wrote:
 ...
 struct S { int a = 1, b = 2, c = 3, d = 4; }

 void main() {
     S w = { d: 9, a: 9, 9 };
     writeln(w);
 }

 The answers:
 ...
Looking the snippet I'd expect the result to be: "A", "B" and "D" to be 9, which is the case according the compiler.
 3. does the last 9 set all the unset vars??
Maybe one thing that might be added for "filling" would be: S w = { d: 9, a: 9, 9... }; // Note the ellipsis "..." Matheus.
Aug 27
prev sibling parent Kagamin <spam here.lot> writes:
On Monday, 26 August 2019 at 22:45:16 UTC, Walter Bright wrote:
 On 8/26/2019 7:47 AM, Kagamin wrote:
 struct S { int a, b, c, d = 7; }
 S w = { c:1, a:1, 3 };
 
 I don't even know if this result is contrived. Maybe it's 
 trivial?
It initializes to: c = 1 a = 1 b = 3 d = 7
I suspect struct initializer is used only in two forms: all named initializers or all positional initializers, so Ada named arguments logic can be used for struct initializer too.
Aug 27
prev sibling next sibling parent reply Olivier FAURE <couteaubleu gmail.com> writes:
On Saturday, 24 August 2019 at 16:36:51 UTC, Andrei Alexandrescu 
wrote:
 On 8/23/19 6:23 PM, Walter Bright 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?
I kinda want to point out that neither you nor Walter have much ground to stand out when it comes to complaining about feedback being ignored. When Walter posted DIP-1021, I gave feedback with detailed examples in multiple occasions (in PR comments and the review thread), wrote a draft for a DIP that will propose an alternate implementation, and posted a type system discussion when I stalled on a problem. I have yet to see any acknowledgment of that work from Walter (atila gave some feedback, though it was fairly surface-level). I'm not saying I'm mad about that; but the way you're saying "Walter's proposal is obviously superior. Why didn't the author drop his DIP and make a new one based on Walter's idea instead?" seems a little naive of how the process tends to go. People usually don't give up on their own ideas to champion someone else's alternative. I don't, you probably don't, and Walter certainly doesn't.
Aug 27
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/27/2019 8:32 AM, Olivier FAURE wrote:
 When Walter posted DIP-1021, I gave feedback with detailed examples in
multiple 
 occasions (in PR comments and the review thread), wrote a draft for a DIP that 
 will propose an alternate implementation, and posted a type system discussion 
 when I stalled on a problem. I have yet to see any acknowledgment of that work 
 from Walter (atila gave some feedback, though it was fairly surface-level).
I have replied to some of it, but not all. I got called away on a crisis and haven't gotten back to it since, even my proposal on it. BTW, when you write that you've made proposals and such, it helps a lot to include links to what you're talking about. You're far more likely get interest in it than if people have to go spelunking around wondering what specifically you're referring to. It's the same advice I give when people say they're blocked by bugs, but never link to the bug reports (and often don't even give a hint as to what the issues are). I try to follow my own advice: https://digitalmars.com/d/archives/digitalmars/D/DIP_1019--Named_Arguments_Lite--Final_Review_330067.html#N330105
Aug 27
parent reply Olivier FAURE <couteaubleu gmail.com> writes:
On Tuesday, 27 August 2019 at 21:15:33 UTC, Walter Bright wrote:
 On 8/27/2019 8:32 AM, Olivier FAURE wrote:
 When Walter posted DIP-1021, I gave feedback with detailed 
 examples in multiple occasions (in PR comments and the review 
 thread), wrote a draft for a DIP that will propose an 
 alternate implementation, and posted a type system discussion 
 when I stalled on a problem. I have yet to see any 
 acknowledgment of that work from Walter (atila gave some 
 feedback, though it was fairly surface-level).
I have replied to some of it, but not all. I got called away on a crisis and haven't gotten back to it since, even my proposal on it. BTW, when you write that you've made proposals and such, it helps a lot to include links to what you're talking about. You're far more likely get interest in it than if people have to go spelunking around wondering what specifically you're referring to.
To be clear, I'm not demanding that you answer what I wrote. You don't owe me anything. I'm just saying Andrei's expectations are a little unrealistic. My feedback on DIP 1021: https://forum.dlang.org/post/imbicsoobfdugegqjozw forum.dlang.org DIP draft for OB semantics: https://gist.github.com/PoignardAzur/9896ddb17b9f6d6f3d0fa5e6fe1a7088 Lifetimes discussion: https://forum.dlang.org/thread/qssaruktegnbtsdjeyri forum.dlang.org
Aug 28
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/28/2019 1:42 AM, Olivier FAURE wrote:
 To be clear, I'm not demanding that you answer what I wrote. You don't owe me 
 anything. I'm just saying Andrei's expectations are a little unrealistic.
 
 My feedback on DIP 1021: 
 https://forum.dlang.org/post/imbicsoobfdugegqjozw forum.dlang.org
 DIP draft for OB semantics: 
 https://gist.github.com/PoignardAzur/9896ddb17b9f6d6f3d0fa5e6fe1a7088
 Lifetimes discussion: 
 https://forum.dlang.org/thread/qssaruktegnbtsdjeyri forum.dlang.org
Thank you!
Aug 28
prev sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, August 27, 2019 9:32:03 AM MDT Olivier FAURE via Digitalmars-d 
wrote:
 On Saturday, 24 August 2019 at 16:36:51 UTC, Andrei Alexandrescu

 wrote:
 On 8/23/19 6:23 PM, Walter Bright wrote:
 I reiterate my previous opinion:

 https://digitalmars.com/d/archives/digitalmars/D/DIP_1019--Named_Argume
 nts_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 kinda want to point out that neither you nor Walter have much ground to stand out when it comes to complaining about feedback being ignored. When Walter posted DIP-1021, I gave feedback with detailed examples in multiple occasions (in PR comments and the review thread), wrote a draft for a DIP that will propose an alternate implementation, and posted a type system discussion when I stalled on a problem. I have yet to see any acknowledgment of that work from Walter (atila gave some feedback, though it was fairly surface-level). I'm not saying I'm mad about that; but the way you're saying "Walter's proposal is obviously superior. Why didn't the author drop his DIP and make a new one based on Walter's idea instead?" seems a little naive of how the process tends to go. People usually don't give up on their own ideas to champion someone else's alternative. I don't, you probably don't, and Walter certainly doesn't.
A significant difference here is that Walter is one of the two people who approves DIPs. So, ignoring his feedback when writing a DIP is likely to mean that it's going to be rejected. That doesn't mean that he's right, and the proposal could very well win him over if its argumentation is improved, but ignoring what the person who's making the decision says is almost certainly going to lead to the DIP being rejected. Given that Walter has given his feedback on how he thinks named arguments should be done, I would think that anyone writing a DIP on named arguments would need to address his feedback in their DIP if they have any hope of it getting accepted. Now, personally, I don't like the idea having named arguments in the language, so it's fine with me if everyone writing DIPs on the matter does so in a way that Walter is going to reject them, but given his position, ignoring his feedback seems like a bad idea for anyone who wants their DIP to be accepted. - Jonathan M Davis
Aug 27
parent reply Olivier FAURE <couteaubleu gmail.com> writes:
On Tuesday, 27 August 2019 at 23:08:11 UTC, Jonathan M Davis 
wrote:
 A significant difference here is that Walter is one of the two 
 people who approves DIPs. So, ignoring his feedback when 
 writing a DIP is likely to mean that it's going to be rejected.
The "Community Review Round 2" section mentions Walter's proposal as a possible superset of the current proposal. I think the problem with this DIP isn't ignoring feedback (it has changed a lot since its initial iteration) so much as a lack of integration of that feedback into a coherent analysis. Like, this DIP has evolved by adding and dropping features to address complaints from reviewers, but it still doesn't really justify these changes or explore the relevant trade-offs and their practical consequences. An ideal DIP would list the possible implementations, their upsides, their downside, how to leverage the former and mitigate the latter, and why a given implementation is better for D than the others. With all that said, I still think the way Andrei asked "well why didn't you just use Walter's version and ignore everything else?" is a little presumptuous.
Aug 28
parent reply nkm1 <t4nk074 openmailbox.org> writes:
On Wednesday, 28 August 2019 at 09:00:08 UTC, Olivier FAURE wrote:
 With all that said, I still think the way Andrei asked "well 
 why didn't you just use Walter's version and ignore everything 
 else?" is a little presumptuous.
Well, it's not just because Walter proposed that. It's also because his proposal is the most obvious one. There is already designated initialization syntax for arrays and structs, so having something different for parameters to a function requires, at least, some justification. Espectially considering the fact that some programming languages don't have named parameters and instead use associative arrays literals (Perl, Lua). sub sum_abc { my $abc = shift; return $abc->{a} + $abc->{b} + $abc->{c}; } print sum_abc({ c => 3, a => 1, b => 2}), "\n"; D doesn't have struct literal syntax (yet?), but C does: #include <stdio.h> typedef struct { int a, b, c; } ABC; int sum_abc(ABC abc) { return abc.a + abc.b + abc.c; } int main(void) { printf("%d\n", sum_abc((ABC) { .c = 3, .a = 1, .b = 2 })); } That looks pretty damn close to named parameters, doesn't it... And it's plausible that one day D will get struct literals (unless it got them while I wasn't looking?) Anyway, it absolutely must be discussed in the DIP (as "Prior Work"), and it doesn't matter whether it's Walter's proposal or anyone else's.
Aug 28
parent reply Olivier FAURE <couteaubleu gmail.com> writes:
On Wednesday, 28 August 2019 at 09:37:13 UTC, nkm1 wrote:
 On Wednesday, 28 August 2019 at 09:00:08 UTC, Olivier FAURE 
 wrote:
 With all that said, I still think the way Andrei asked "well 
 why didn't you just use Walter's version and ignore everything 
 else?" is a little presumptuous.
Well, it's not just because Walter proposed that. It's also because his proposal is the most obvious one. There is already designated initialization syntax for arrays and structs, so having something different for parameters to a function requires, at least, some justification. Espectially considering the fact that some programming languages don't have named parameters and instead use associative arrays literals (Perl, Lua).
I don't think it's obvious. There's trade-offs to consider, that people have spent pages debating.
Aug 29
parent nkm1 <t4nk074 openmailbox.org> writes:
On Thursday, 29 August 2019 at 21:53:36 UTC, Olivier FAURE wrote:
 On Wednesday, 28 August 2019 at 09:37:13 UTC, nkm1 wrote:
 I don't think it's obvious.
I guess it depends on whether you see functions parameters as a kind of struct (or both structs and parameters as kinds of tuple). Too me, they look almost indistinguishable. In any case, D already has certain rules for initializing structs and arrays, and the same rules _can_ be applied to parameters, so, using a variant of Occam's razor here...
 There's trade-offs to consider, that people have spent pages 
 debating.
That's what I'm saying, no? The DIP should discuss these trade-offs (but it doesn't). Maybe D doesn't even need named parameters. Perhaps C-style struct literals with designated initializers would be perfectly sufficient (and more useful in general, and that also would adress Jonathan Davis' concerns about rewriting Phobos). That all should be discussed in the DIP.
Aug 29
prev sibling next sibling parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
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.
It _has not been_ ignored. But, it is just a feedback, not a DIP. So, due process, it is not to be treated with the same weight as a DIP.
 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.
Yes, so please, please write a DIP for that proposal.
 This entire dynamics strikes me as massively counterproductive. 
 Why are we doing this?
Yes, why are we doing this?
Aug 27
parent nkm1 <t4nk074 openmailbox.org> writes:
On Tuesday, 27 August 2019 at 16:47:24 UTC, Yuxuan Shui wrote:
 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.
It _has not been_ ignored. But, it is just a feedback, not a DIP. So, due process, it is not to be treated with the same weight as a DIP.
So the DIP should definitely address the designated initializers thing (presumably in the "Prior Work" section). It should explain why named parameters must use different rules. Otherwise, the DIP is incomplete.
 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.
Yes, so please, please write a DIP for that proposal.
The currently discussed DIP can be rejected without writing any new one...
Aug 28
prev sibling parent krzaq <dlangmailinglist krzaq.cc> writes:
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 thought it was ignored because allowing mixing of positional and named arguments is terrible for readability. That is, of course, my opinion - but I didn't treat it as a serious competition until you mentioned it.
Aug 28
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
For reference, the previous discussion threads:

Round 1:

https://digitalmars.com/d/archives/digitalmars/D/DIP_1019--Named_Arguments_Lite--Community_Review_Round_1_324110.html

Round 2:

https://digitalmars.com/d/archives/digitalmars/D/DIP_1019--Named_Arguments_Lite--Community_Review_Round_2_327714.html
Aug 23
prev sibling next sibling parent 12345swordy <alexanderheistermann gmail.com> writes:
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
Aug 24
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
I feel this DIP is bashed a bit too heavily here.

I do share the concern of most people that the DIP should include 
at least some argument reordering. My impression is that you 
removed the reordering you had at community review one to avoid 
the ` named` parameter, that was not well received by some.

Unfortunately, preventing all argument reordering just does not 
work. Like many have said, such named parameters would be tedious 
and likely unpopular to use. But there is another problem too, 
one that had you to include argument reordering in the draft 
stage, I believe:

´´´
foo(int a, int b)
foo(double b, int a)
´´´

If the dip will consider argument reordering, a call `foo(a:3, 
b:3)` can be specified as an ambiguous call, triggering a 
compiler error. However, if your DIP as now is implemented, that 
call would bind to the first function, preventing ambiguity 
checking later on, without core breakage. As long as you have 
this problem, it defeats the purpose of "less-is-more" philosophy.

No, you need at least some form of argument reordering. It could 
be along the lines of what Walter proposed, or something like 
Rikki's base idea (named parameters being separated from unnamed 
ones on API, and overload only by unnamed params).

This all being said, you actually wrote a DIP. It's easy to bash 
the concept when one has to consider only the concept, not corner 
cases and specification. I don't agree with Andrei: writing a DIP 
with argument reordering would be a major undertaking, just as 
difficult and very possibly more so than this one with all the 
corner cases to consider. We can't except to easily find a 
champion for that.

Perhaps this DIP can be used incrementally after all, just not by 
including it to D as-is. If Rikki's DIP won't get through, and if 
someone wants to write a real DIP from Walter's proposal, a lot 
of the details are already ready if you paper is used as base. 
Even better, if you don't want to do it yourself, you can abandon 
the DIP. That way someone can just stick argument reordering in 
and go straight to community review past the draft queue (Or can 
they? Mike?).
Aug 26
parent Kagamin <spam here.lot> writes:
On Tuesday, 27 August 2019 at 05:21:55 UTC, Dukc wrote:
 This all being said, you actually wrote a DIP. It's easy to 
 bash the concept when one has to consider only the concept, not 
 corner cases and specification. I don't agree with Andrei: 
 writing a DIP with argument reordering would be a major 
 undertaking, just as difficult and very possibly more so than 
 this one with all the corner cases to consider. We can't except 
 to easily find a champion for that.
It's not very obvious, but straightforward enough: when evaluating best match for named arguments, match parameters by name instead of position.
Aug 27