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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
prev 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
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
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