Re: DIP 1030-- Named Arguments--Formal Assessment
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
Re: DIP 1030-- Named Arguments--Formal Assessment
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.digitalmar...@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.
Re: DIP 1030-- Named Arguments--Formal Assessment
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.
Re: DIP 1030-- Named Arguments--Formal Assessment
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
Re: DIP 1030-- Named Arguments--Formal Assessment
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.
Re: DIP 1030-- Named Arguments--Formal Assessment
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.digitalmar...@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é
Re: DIP 1030-- Named Arguments--Formal Assessment
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.
Re: DIP 1030-- Named Arguments--Formal Assessment
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?
Re: DIP 1030-- Named Arguments--Formal Assessment
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 :)
Re: DIP 1030-- Named Arguments--Formal Assessment
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?
Re: DIP 1030-- Named Arguments--Formal Assessment
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.
Re: DIP 1030-- Named Arguments--Formal Assessment
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.
Re: DIP 1030-- Named Arguments--Formal Assessment
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.
Re: DIP 1030-- Named Arguments--Formal Assessment
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.
Re: DIP 1030-- Named Arguments--Formal Assessment
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.
Re: DIP 1030-- Named Arguments--Formal Assessment
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
Re: DIP 1030-- Named Arguments--Formal Assessment
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?
Re: DIP 1030-- Named Arguments--Formal Assessment
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 ...
Re: DIP 1030-- Named Arguments--Formal Assessment
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/ ;-)
Re: DIP 1030-- Named Arguments--Formal Assessment
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 :-)
Re: DIP 1030-- Named Arguments--Formal Assessment
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.
Re: DIP 1030-- Named Arguments--Formal Assessment
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.digitalmar...@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.
Re: DIP 1030-- Named Arguments--Formal Assessment
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
Re: DIP 1030-- Named Arguments--Formal Assessment
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
