www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DIP 1030-- Named Arguments--Formal Assessment

reply Mike Parker <aldacron gmail.com> writes:
DIP 1030, "Named Arguments", has been accepted.

During the assessment, Walter and Atila had a discussion 
regarding this particular criticism:

https://forum.dlang.org/post/mailman.1117.1581368593.31109.digitalmars-d puremagic.com

"Named arguments breaks this very important pattern:

auto wrapper(alias origFun)(Parameters!origFun args)
{
   // special sauce
   return origFun(args);
}"

They say that, though it's true that `Parameters!func` will not 
work in a wrapper, it "doesn't really work now"---default 
arguments and storage classes must be accounted for. This can be 
done with string mixins, or using a technique referred to by 
Jean-Louis Leroy as "refraction", both of which are clumsy.

So they decided that a new `std.traits` template and a 
corresponding `__traits` option are needed which expand into the 
exact function signature of another function.

They also acknowledge that when an API's parameter names change, 
code depending on the old parameter names will break. Struct 
literals have the same problem and no one complains (the same is 
true for C99). And in any case, when such a change occurs, it's a 
hard failure as any code using named arguments with the old 
parameter names will fail to compile, making it easy to see how 
to resolve the issue. Given this, they find the benefits of the 
feature outweigh the potential for such breakage.
Sep 17 2020
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 17 September 2020 at 12:58:06 UTC, Mike Parker wrote:

 DIP 1030, "Named Arguments", has been accepted.


https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1030.md
Sep 17 2020
next sibling parent 12345swordy <alexanderheistermann gmail.com> writes:
On Thursday, 17 September 2020 at 12:59:05 UTC, Mike Parker wrote:

 On Thursday, 17 September 2020 at 12:58:06 UTC, Mike Parker 
 wrote:

 DIP 1030, "Named Arguments", has been accepted.


 https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1030.md


YES, YES, YES, I had argue in favor of this dip so hard in the 
past years. Thank you Walter.

-Alex
Sep 17 2020
prev sibling next sibling parent reply Martin Tschierschke <mt smartdolphin.de> writes:
On Thursday, 17 September 2020 at 12:59:05 UTC, Mike Parker wrote:

 On Thursday, 17 September 2020 at 12:58:06 UTC, Mike Parker 
 wrote:

 DIP 1030, "Named Arguments", has been accepted.


 https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1030.md


I am happy with that, too. So what is the estimated time frame 
for getting it in dmd?
Sep 21 2020
parent aberba <karabutaworld gmail.com> writes:
On Monday, 21 September 2020 at 09:07:39 UTC, Martin Tschierschke 
wrote:

 On Thursday, 17 September 2020 at 12:59:05 UTC, Mike Parker 
 wrote:

 On Thursday, 17 September 2020 at 12:58:06 UTC, Mike Parker 
 wrote:

 DIP 1030, "Named Arguments", has been accepted.


 https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1030.md


 I am happy with that, too. So what is the estimated time frame 
 for getting it in dmd?


Good question :)
Sep 21 2020
prev sibling parent ddcovery <antoniocabreraperez gmail.com> writes:
On Thursday, 17 September 2020 at 12:59:05 UTC, Mike Parker wrote:

 On Thursday, 17 September 2020 at 12:58:06 UTC, Mike Parker 
 wrote:

 DIP 1030, "Named Arguments", has been accepted.


 https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1030.md


Fantastic news.

The fact that it is a caller decision to use or not names 
emphasizes the D "syntax sugar" oriented conventions (like "dot 
notation"): same method can be called using the way it fits 
better with your on convention.

countOcurrences("hello", "e");
"hello".countOcurrences("e");
"hello".countOcurrences(of:"e"),
countOcurrences(of:"e", in:"hello");

I use rdmd as scripting tool, and I have to say that I will adopt 
immediately named parameters usage:  in addition to scope(...), 
ranges and the simplicity/power of the standard library, D 
becomes an expressive and powerful scripting language.
Nov 18 2020
prev sibling next sibling parent reply Jean-Louis Leroy <jl leroy.nyc> writes:
On Thursday, 17 September 2020 at 12:58:06 UTC, Mike Parker wrote:

 DIP 1030, "Named Arguments", has been accepted.

 During the assessment, Walter and Atila had a discussion 
 regarding this particular criticism:

 https://forum.dlang.org/post/mailman.1117.1581368593.31109.digitalmars-d puremagic.com

 "Named arguments breaks this very important pattern:

 auto wrapper(alias origFun)(Parameters!origFun args)
 {
   // special sauce
   return origFun(args);
 }"

 They say that, though it's true that `Parameters!func` will not 
 work in a wrapper, it "doesn't really work now"---default 
 arguments and storage classes must be accounted for. This can 
 be done with string mixins, or using a technique referred to by 
 Jean-Louis Leroy as "refraction", both of which are clumsy.


Actually, Parameters!origFun will carry storage classes, UDAs, 
etc for all the parameters. And Parameters!origFun[0..1] (note 
the two dots) will carry everything about the first parameter. 
The trouble begins when, for some reason, you need to manipulate 
the parameter at a finer level. For example, in openmethods, I 
need to change the type while preserving everything else.
Sep 17 2020
parent reply Jean-Louis Leroy <jl leroy.nyc> writes:
On Thursday, 17 September 2020 at 13:23:38 UTC, Jean-Louis Leroy 
wrote:

 Actually, Parameters!origFun will carry storage classes, UDAs, 
 etc for all the parameters. And Parameters!origFun[0..1] (note 
 the two dots) will carry everything about the first parameter. 
 The trouble begins when, for some reason, you need to 
 manipulate the parameter at a finer level. For example, in 
 openmethods, I need to change the type while preserving 
 everything else.


(For the rest of this post, to make things clear, I will call 
Parameter declarations that appear inside the function 
definition, and Arguments the values that are passed to a 
function call).

I like named arguments. However, I would be greatly disappointed 
if:
1/ Parameters!origFun and Parameters!origFun[i..i+1] stopped 
working as well as they do now.
2/ The named arguments did not come with new traits (or at least 
is(__parameter) magic) to allow fully analyzing the parameters.

That being said, does the new feature imply any change in the 
*parameters* themselves? I.e. are there changes in the way the 
function is defined, not only in the way it is called?

I have not followed the discussion and just skimmed over the DIP 
now. I'm going to try to find time for this. However, at this 
point I have some hope that the DIP is not damaging in the way 
Mike thinks.
Sep 17 2020
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 17 September 2020 at 13:42:47 UTC, Jean-Louis Leroy 
wrote:


 this point I have some hope that the DIP is not damaging in the 
 way Mike thinks.


What Mike thinks appears nowhere in my post :-)
Sep 17 2020
next sibling parent Jean-Louis Leroy <jl leroy.nyc> writes:
On Thursday, 17 September 2020 at 13:45:16 UTC, Mike Parker wrote:

 On Thursday, 17 September 2020 at 13:42:47 UTC, Jean-Louis 
 Leroy wrote:


 this point I have some hope that the DIP is not damaging in 
 the way Mike thinks.


 What Mike thinks appears nowhere in my post :-)


OK, s/thinks/reports/ ;-)
Sep 17 2020
prev sibling parent reply Cym13 <cpicard purrfect.fr> writes:
On Thursday, 17 September 2020 at 13:45:16 UTC, Mike Parker wrote:

 What Mike thinks appears nowhere in my post :-)


That's a bit sad. I understand that in your position it may be 
hard to express a personnal opinion but I think anyone should get 
the opportunity to do so. Would you like, in no official capacity 
whatsoever, to provide your personnal take on the matter?

I think you should get to express your feelings as well :) But of 
course I would understand if you don't want to get involved in 
any particular issue.
Sep 17 2020
parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 17 September 2020 at 20:13:23 UTC, Cym13 wrote:

 On Thursday, 17 September 2020 at 13:45:16 UTC, Mike Parker 
 wrote:

 What Mike thinks appears nowhere in my post :-)


 That's a bit sad. I understand that in your position it may be 
 hard to express a personnal opinion but I think anyone should 
 get the opportunity to do so. Would you like, in no official 
 capacity whatsoever, to provide your personnal take on the 
 matter?


I think you took that comment the wrong way :-) The announcement 
provides the rationale behind the decision Walter and Atila made. 
I just wanted to make it clear for anyone reading Jean-Louis's 
comment that I wasn't posting my opinion. For the record, I have 
no opinion on this DIP one way or another. Named arguments don't 
interest me at all.



 I think you should get to express your feelings as well :) But 
 of course I would understand if you don't want to get involved 
 in any particular issue.


Given that I work closely with DIP authors to revise their DIPs, 
and that sometimes that involves more than just proofreading, I 
don't think it's appropriate for me to publicly take a position 
on any of them. I don't want any author to feel I have an 
ulterior motive in any content revision suggestions I make, and I 
don't want to color my own judgement.
Sep 17 2020
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/17/2020 6:42 AM, Jean-Louis Leroy wrote:

 That being said, does the new feature imply any change in the *parameters* 
 themselves?


No.


 I.e. are there changes in the way the function is defined,


No.


 not only in the way it is called?


It only affects calling syntax in providing an alternative way to call a
function.
Sep 17 2020
prev sibling next sibling parent angel <andrey.gelman gmail.com> writes:
On Thursday, 17 September 2020 at 12:58:06 UTC, Mike Parker wrote:

 DIP 1030, "Named Arguments", has been accepted.


I would really want to see tuples ...
Sep 17 2020
prev sibling next sibling parent aberba <karabutaworld gmail.com> writes:
On Thursday, 17 September 2020 at 12:58:06 UTC, Mike Parker wrote:

 DIP 1030, "Named Arguments", has been accepted.

 During the assessment, Walter and Atila had a discussion 
 regarding this particular criticism:

 [...]


Calls for celebration... who's in?
Sep 17 2020
prev sibling next sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 9/17/20 8:58 AM, Mike Parker wrote:

 So they decided that a new `std.traits` template and a corresponding 
 `__traits` option are needed which expand into the exact function 
 signature of another function.


This, sounds great. I'd love to see the specifics for this.

Also, I am very much looking forward to named parameters! I hope call 
forwarding can be done in a simple a way as it's done now.

-Steve
Sep 17 2020
prev sibling next sibling parent reply Jean-Louis Leroy <jl leroy.nyc> writes:
On Thursday, 17 September 2020 at 12:58:06 UTC, Mike Parker wrote:


 So they decided that a new `std.traits` template and a 
 corresponding `__traits` option are needed which expand into 
 the exact function signature of another function.


I have been trying to locate that specific discussion, without 
success so far. Help? This is of great interest to me, and I may 
throw in my $.02.
Sep 18 2020
parent reply Mike Parker <aldacron gmail.com> writes:
On Friday, 18 September 2020 at 13:34:30 UTC, Jean-Louis Leroy 
wrote:

 On Thursday, 17 September 2020 at 12:58:06 UTC, Mike Parker 
 wrote:


 So they decided that a new `std.traits` template and a 
 corresponding `__traits` option are needed which expand into 
 the exact function signature of another function.


 I have been trying to locate that specific discussion, without 
 success so far. Help? This is of great interest to me, and I 
 may throw in my $.02.


It's from a phone call they had while they were discussing 
whether to approve or reject the DIP.
Sep 18 2020
parent Jean-Louis Leroy <jl leroy.nyc> writes:
On Friday, 18 September 2020 at 13:39:14 UTC, Mike Parker wrote:


 It's from a phone call they had while they were discussing 
 whether to approve or reject the DIP.


LOL no wonder I couldn't find it.
Sep 18 2020
prev sibling next sibling parent Dukc <ajieskola gmail.com> writes:
On Thursday, 17 September 2020 at 12:58:06 UTC, Mike Parker wrote:

 DIP 1030, "Named Arguments", has been accepted.


Good. It has some weaknesses that Rikki's DIP would have avoided 
but it's also simpler. Good work, Walter!


 "Named arguments breaks this very important pattern:

 auto wrapper(alias origFun)(Parameters!origFun args)
 {
   // special sauce
   return origFun(args);
 }"


I'm not worried about this one, as AFAIK this does not really 
break, it just needs changes to work with the new feature.
Sep 18 2020
prev sibling next sibling parent reply Arun <aruncxy gmail.com> writes:
On Thursday, 17 September 2020 at 12:58:06 UTC, Mike Parker wrote:

 DIP 1030, "Named Arguments", has been accepted.
...


Mike, thanks for pulling this together. This question from the 
feedback thread is still unanswered.


 How does the compiler handle function lookup when there is an 
 ambiguous match, but the ambiguous function is in a different 
 module?


What would be the solution?
Sep 23 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/23/2020 7:01 AM, Arun wrote:

 How does the compiler handle function lookup when there is an ambiguous match, 
 but the ambiguous function is in a different module?


 
 What would be the solution?


The same way it handles it without named arguments - an error.
Sep 23 2020
prev sibling next sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Thursday, 17 September 2020 at 12:58:06 UTC, Mike Parker wrote:

 DIP 1030, "Named Arguments", has been accepted.

 During the assessment, Walter and Atila had a discussion 
 regarding this particular criticism:

 https://forum.dlang.org/post/mailman.1117.1581368593.31109.digitalmars-d puremagic.com

 "Named arguments breaks this very important pattern:

 auto wrapper(alias origFun)(Parameters!origFun args)
 {
   // special sauce
   return origFun(args);
 }"

 They say that, though it's true that `Parameters!func` will not 
 work in a wrapper, it "doesn't really work now"---default 
 arguments and storage classes must be accounted for. This can 
 be done with string mixins, or using a technique referred to by 
 Jean-Louis Leroy as "refraction", both of which are clumsy.

 So they decided that a new `std.traits` template and a 
 corresponding `__traits` option are needed which expand into 
 the exact function signature of another function.

 They also acknowledge that when an API's parameter names 
 change, code depending on the old parameter names will break. 
 Struct literals have the same problem and no one complains (the 
 same is true for C99). And in any case, when such a change 
 occurs, it's a hard failure as any code using named arguments 
 with the old parameter names will fail to compile, making it 
 easy to see how to resolve the issue. Given this, they find the 
 benefits of the feature outweigh the potential for such 
 breakage.


Hi,

how to this new feature interact with opDispatch? Will there be 
any possibility
to extract the argument names in opDispatch?

If yes, this "might" increase the usability of pyd:
auto df = pd.DataFrame.unpack_call(
   py(tuple()),
   py(tuple!("data", "columns")(numpyArray, py(["a", "b"]))));

vs.

auto df = pd.DataFrame(data=numpyArray, columns=["a", "b"]);

Kind regards
André
Oct 08 2020
parent reply Q. Schroll <qs.il.paperinik gmail.com> writes:
On Thursday, 8 October 2020 at 14:05:14 UTC, Andre Pany wrote:

 how to this new feature interact with opDispatch? Will there be 
 any possibility to extract the argument names in opDispatch?


Good catch. The DIP doesn't mention opDispatch and it's probably 
too late to change. I also don't really see a non-breaking way to 
tell opDispatch about parameter names.
Giving opDispatch a string[] of named arguments' names (with "" 
for a name-less argument) would probably do the job, but it's a 
breaking change.

A different solution would be a new operator method called 
`opDispatchNamed` or alike that does exactly that. However, 
opDispatch is designed to be used when `c` in expr.c cannot be 
resolved, where expr.c(args) is a special case where `c` happens 
to be "something callable".

I'd say, the problem should be solved on a more general level: 
function templates *in general* (opDispatch included) should have 
a way to get named arguments' names. One possibility would be a 
magic __ARG_NAMES__ that returns a compile-time string[] that 
contains that names, like __FILE__ and __LINE__ at call site if 
used as a default parameter. So you'd use it like:

     auto opDispatch(
         string methodName,
         string[] argNames = __ARG_NAMES__,
         T, Ts...
     )(T arg, Ts args)
     {
         // argNames[0] will be "arg" always since it's not an 
pack.
     }

That way, it could be non-breaking and more useful.
Oct 27 2020
parent Andre Pany <andre s-e-a-p.de> writes:
On Wednesday, 28 October 2020 at 02:22:14 UTC, Q. Schroll wrote:

 On Thursday, 8 October 2020 at 14:05:14 UTC, Andre Pany wrote:

 [...]


 Good catch. The DIP doesn't mention opDispatch and it's 
 probably too late to change. I also don't really see a 
 non-breaking way to tell opDispatch about parameter names.
 Giving opDispatch a string[] of named arguments' names (with "" 
 for a name-less argument) would probably do the job, but it's a 
 breaking change.

 [...]


Thank you a lot for your analysis. Once the feature is 
implemented I will create a feature request and add your proposal.

Kind regards
Andre
Oct 28 2020
prev sibling parent reply zoujiaqing <zoujiaqing gmail.com> writes:
On Thursday, 17 September 2020 at 12:58:06 UTC, Mike Parker wrote:

 DIP 1030, "Named Arguments", has been accepted.

 During the assessment, Walter and Atila had a discussion 
 regarding this particular criticism:

 https://forum.dlang.org/post/mailman.1117.1581368593.31109.digitalmars-d puremagic.com

 "Named arguments breaks this very important pattern:

 auto wrapper(alias origFun)(Parameters!origFun args)
 {
   // special sauce
   return origFun(args);
 }"

 They say that, though it's true that `Parameters!func` will not 
 work in a wrapper, it "doesn't really work now"---default 
 arguments and storage classes must be accounted for. This can 
 be done with string mixins, or using a technique referred to by 
 Jean-Louis Leroy as "refraction", both of which are clumsy.

 So they decided that a new `std.traits` template and a 
 corresponding `__traits` option are needed which expand into 
 the exact function signature of another function.

 They also acknowledge that when an API's parameter names 
 change, code depending on the old parameter names will break. 
 Struct literals have the same problem and no one complains (the 
 same is true for C99). And in any case, when such a change 
 occurs, it's a hard failure as any code using named arguments 
 with the old parameter names will fail to compile, making it 
 easy to see how to resolve the issue. Given this, they find the 
 benefits of the feature outweigh the potential for such 
 breakage.


Very practical features, similar to trailing closures, are 
expected.
Dec 07 2020
parent Andre Pany <andre s-e-a-p.de> writes:
On Monday, 7 December 2020 at 12:13:35 UTC, zoujiaqing wrote:

 On Thursday, 17 September 2020 at 12:58:06 UTC, Mike Parker 
 wrote:

 [...]


 Very practical features, similar to trailing closures, are 
 expected.


Implementing the DIP is added to the list of possible gsoc21 
projects. Hopefully D is this year elected.

https://github.com/dlang/projects/issues/76

It will also make porting python libraries to D easier as it 
minimizes coding differences.

Kind regards
Andre
Dec 07 2020