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 2019
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 2019
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 2019
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 2019
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 2019
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
Remove the sections about variadic functions and unnamed 
parameters.
Aug 23 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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
Aug 23 2019
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



Noice!
Aug 23 2019
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




 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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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?

the positional arguments

foo( 0, b:10); // foo( int, int) no doubts
Aug 23 2019
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.



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

`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 2019
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 2019
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.



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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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?"

pet/toy/too_constrained named args?
I think cuz it enough for everything/everybody and behind that 
line lives dragons.
Aug 24 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
parent reply Kagamin <spam here.lot> writes:
And description of algorithm is unclear 
https://dlang.org/spec/struct.html#static_struct_init
Aug 26 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 

it didn't do enough.

-Alex
Aug 24 2019
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 2019
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 2019