This is the discussion thread for the Final Review of DIP 1030, "Named Arguments":

https://github.com/dlang/DIPs/blob/7d114c93edb02d8fc4b05f0716bdb6057905fec2/DIPs/DIP1030.md

The review period will end at 11:59 PM ET on May 25, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.

Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits, etc.

However, if you have any specific feedback on how to improve the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary I write at the end of this review round. I will post a link to that thread immediately following this post. Just be sure to read and understand the Reviewer Guidelines before posting there:

https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

And my blog post on the difference between the Discussion and Feedback threads:

https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/

Please stay on topic here. I will delete posts that are completely off-topic.

On Monday, 11 May 2020 at 11:37:07 UTC, Mike Parker wrote:

> However, if you have any specific feedback on how to improve the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary I write at the end of this review round. I will post a link to that thread immediately following this post.

The Feedback Thread is here:

https://forum.dlang.org/post/lzpzaoaxzcxeijegfhkz@forum.dlang.org

The biggest problem I had with this DIP still remains -- You cannot forward the "namedness" of parameters to a subtype.

Consider the following, which is supposed to wrap a subtype:

struct S
{
    int foo(int bar) {...}
}

struct LogCalls!T
{
   private T _wrapped;
   auto ref opDispatch(string f, Args...)(auto ref Args args)
   {
       log("Calling ", f);
       mixin("return " ~ f ~ "(args);");
   }
}

This works today and can be used to reasonably wrap everything that T can do.

But with this named parameters DIP, then we have problems:

// S s;
LogCalls!S s; // I want to log things temporarily

s.foo(bar: 5); // error

I think this is important to solve. Because you have types whose "API" is "I will wrap everything this type does", and this breaks the promise with no possibility of a fix. While everything that compiles today will compile tomorrow, code will migrate to using named args, and then you can't use these wrappers, or you have to explicitly forbid users from using named arguments.

Discussed here: https://forum.dlang.org/post/mailman.1114.1581363532.31109.digitalmars-d@puremagic.com

And this was my reply at that time:
https://forum.dlang.org/post/r1uaph$2pkl$1@digitalmars.com

A possible solution is to accept a string[] arg as the first parameter in opDispatch, so the names can be captured. This also allows an opt-in so current opDispatch cannot be called via named parameters.

Another possible mechanism is to provide a __traits call to get argument names, but the issue here is that then you can call code that isn't written to handle named args with named args and the right thing might not happen.

Another possibility is to provide a second variadic parameter e.g.:

opDispatch(string f, Args..., string[] names...)(Args args)

Where names will be filled in with the names provided by the caller, or null if not provided.

This is also a nice opt-in, as it doesn't compile today.

-Steve

On 5/11/2020 5:48 AM, Steven Schveighoffer wrote:
> The biggest problem I had with this DIP still remains -- You cannot forward the "namedness" of parameters to a subtype.

I see this as something you can propose as another DIP to enhance DIP1030 after it is incorporated.

On Monday, 11 May 2020 at 11:37:07 UTC, Mike Parker wrote:
> This is the discussion thread for the Final Review of DIP 1030, "Named Arguments":
>
> https://github.com/dlang/DIPs/blob/7d114c93edb02d8fc4b05f0716bdb6057905fec2/DIPs/DIP1030.md
>
> The review period will end at 11:59 PM ET on May 25, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.
>
> Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits, etc.
>
> However, if you have any specific feedback on how to improve the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary I write at the end of this review round. I will post a link to that thread immediately following this post. Just be sure to read and understand the Reviewer Guidelines before posting there:
>
> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>
> And my blog post on the difference between the Discussion and Feedback threads:
>
> https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/
>
> Please stay on topic here. I will delete posts that are completely off-topic.

I'd really like to see the DIP include a proposal on parameter naming conventions for the standard libraries before we enable this.

For example, Walter mentioned in the discussion thread that when creating function wrappers for external APIs, we should use the same name from the original function. (see https://forum.dlang.org/post/r1us6g$11gs$1@digitalmars.com). However I don't see this convention mentioned anywhere in the DIP and I don't think the choice to do it this way is "self-evident".

Coming up with conventions after we enable this could cause quite a bit of headache and debate about when to create wrappers to support old parameter name overloads and how much time before we remove the deprecations.  There will be much less "friction" to fix these names if we do so before enabling the feature.

Here's a start for how these conventions could look:

Parameter Naming Conventions
---------------------------------------------------------------------
First, the parameter names of a function should only be modified if exposing the names helps the caller in some way.  For example, you needn't bother with the name of the parameter in a function such as "floor":

floor(x);
floor(x:x); // not helpful

A sleep function that takes milliseconds on the other hand could be helpful:

sleep(100);
sleep(msecs:100); // helpful

Given that, here are a list of conventions:

1. When wrapping another API, use the names from the original.

For example, all Windows functions should use the names from the original Windows headers and documentation.

2. Common generic parameter names

p (generic pointer argument, prefer this over ptr or pointer)
s (generic string argument, prefer this over str or string)
i (generic integer argument)
msecs
secs

3. ...


I feel that including a set of conventions in the DIP will be worth the effort now, and save us from alot of effort later, even if it ends up delaying this feature to a degree.

On Tuesday, 12 May 2020 at 05:36:11 UTC, Walter Bright wrote:
> On 5/11/2020 5:48 AM, Steven Schveighoffer wrote:
>> The biggest problem I had with this DIP still remains -- You cannot forward the "namedness" of parameters to a subtype.
>
> I see this as something you can propose as another DIP to enhance DIP1030 after it is incorporated.

It's a feature that would be lost, I don't think named arguments should be included without this feature. Without ironing out the details now, who's to say that a suitable solution exists to the problem? There's no obvious solution to a problem that should be solved.


I also don't like that you can rearrange the arguments into a different order. Especially that you can put default arguments in the middle. By doing so you are forcing users to use named arguments or not use defaults at all. As an example, in C# only allows defaults at the end, and named arguments still need to be in the correct order. I don't see *any* benefit, nor does the DIP describe what benefit this provides. On the other hand this makes it more difficult to read, especially (as with the example) both functions have the same exact names for their parameters. THIS is a feature that should be removed, and if it is deemed necessary at a later date then it can be incorporated with another DIP. Otherwise trying to fix this later on when it is already in use will be almost impossible without breaking any code that uses it.

On Tuesday, 12 May 2020 at 12:11:11 UTC, Gregory wrote:
> On Tuesday, 12 May 2020 at 05:36:11 UTC, Walter Bright wrote:
>> On 5/11/2020 5:48 AM, Steven Schveighoffer wrote:
>>> The biggest problem I had with this DIP still remains -- You cannot forward the "namedness" of parameters to a subtype.
>>
>> I see this as something you can propose as another DIP to enhance DIP1030 after it is incorporated.
>
> It's a feature that would be lost, I don't think named arguments should be included without this feature. Without ironing out the details now, who's to say that a suitable solution exists to the problem? There's no obvious solution to a problem that should be solved.
>
>
> I also don't like that you can rearrange the arguments into a different order. Especially that you can put default arguments in the middle. By doing so you are forcing users to use named arguments or not use defaults at all. As an example, in C# only allows defaults at the end, and named arguments still need to be in the correct order. I don't see *any* benefit, nor does the DIP describe what benefit this provides. On the other hand this makes it more difficult to read, especially (as with the example) both functions have the same exact names for their parameters. THIS is a feature that should be removed, and if it is deemed necessary at a later date then it can be incorporated with another DIP. Otherwise trying to fix this later on when it is already in use will be almost impossible without breaking any code that uses it.

That is no longer the case as of C# 8, the rules have been made more flexible.

On Tuesday, 12 May 2020 at 12:40:47 UTC, Paulo Pinto wrote:
> On Tuesday, 12 May 2020 at 12:11:11 UTC, Gregory wrote:
>> On Tuesday, 12 May 2020 at 05:36:11 UTC, Walter Bright wrote:
>>> On 5/11/2020 5:48 AM, Steven Schveighoffer wrote:
>>>> The biggest problem I had with this DIP still remains -- You cannot forward the "namedness" of parameters to a subtype.
>>>
>>> I see this as something you can propose as another DIP to enhance DIP1030 after it is incorporated.
>>
>> It's a feature that would be lost, I don't think named arguments should be included without this feature. Without ironing out the details now, who's to say that a suitable solution exists to the problem? There's no obvious solution to a problem that should be solved.
>>
>>
>> I also don't like that you can rearrange the arguments into a different order. Especially that you can put default arguments in the middle. By doing so you are forcing users to use named arguments or not use defaults at all. As an example, in C# only allows defaults at the end, and named arguments still need to be in the correct order. I don't see *any* benefit, nor does the DIP describe what benefit this provides. On the other hand this makes it more difficult to read, especially (as with the example) both functions have the same exact names for their parameters. THIS is a feature that should be removed, and if it is deemed necessary at a later date then it can be incorporated with another DIP. Otherwise trying to fix this later on when it is already in use will be almost impossible without breaking any code that uses it.
>
> That is no longer the case as of C# 8, the rules have been made more flexible.

Link? It was relaxed in C# 7.2 but I don't see anything for C# 8 that relaxes them further. But it didn't change the requirement for defaults or positioning.

On Tuesday, 12 May 2020 at 13:08:52 UTC, Gregory wrote:
> On Tuesday, 12 May 2020 at 12:40:47 UTC, Paulo Pinto wrote:
>> On Tuesday, 12 May 2020 at 12:11:11 UTC, Gregory wrote:
>>> [...]
>>
>> That is no longer the case as of C# 8, the rules have been made more flexible.
>
> Link? It was relaxed in C# 7.2 but I don't see anything for C# 8 that relaxes them further. But it didn't change the requirement for defaults or positioning.

You're right I was mixing that with now being able to change the order of named arguments.

On Tuesday, 12 May 2020 at 12:11:11 UTC, Gregory wrote:
> I also don't like that you can rearrange the arguments into a different order. Especially that you can put default arguments in the middle. By doing so you are forcing users to use named arguments or not use defaults at all. As an example, in C# only allows defaults at the end, and named arguments still need to be in the correct order. I don't see *any* benefit, nor does the DIP describe what benefit this provides. On the other hand this makes it more difficult to read, especially (as with the example) both functions have the same exact names for their parameters. THIS is a feature that should be removed, and if it is deemed necessary at a later date then it can be incorporated with another DIP. Otherwise trying to fix this later on when it is already in use will be almost impossible without breaking any code that uses it.

The logic behind this feature is that the rules it uses for re-ordering are the same ones already used for struct initializers [1], which are in turn based on the rules used for designated initializers in C99 [2].

These rules aren't perfect, but consistently using the same rules for everything is much better than having two separate sets of rules, and it's too late to go back and change the struct-initialization syntax now.

[1] https://dlang.org/spec/struct.html#static_struct_init
[2] http://port70.net/~nsz/c/c99/n1256.html#6.7.8p17