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.

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

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

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.

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.

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 :-)

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/ ;-)

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

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.

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?