On Tuesday, 10 September 2019 at 15:07:49 UTC, rikki cattermole wrote:
> On 11/09/2019 2:52 AM, Paul Backus wrote:
>> On Tuesday, 10 September 2019 at 14:19:02 UTC, rikki cattermole wrote:
>>>> 2. Way too much verbiage for declaring functions with named arguments.
>>>> 3.I still think the code breakage caused by named arguments is still overblown, I never encounter anyone in the C# who complains about code breakage regarding named arguments.
>>>
>>> The design C# has taken, was more restrictive and quite importantly more conservative than both mine and Walter's.
>>>
>>> That may have been a key factor in it not breaking peoples code.
>> 
>> Having read DIP 1020, Walter's proposal, and the C# article, the only difference I can find (leaving aside the parts about templates) is that C# is more restrictive about how named arguments may be reordered. I fail to see how this difference could possibly have any impact on the potential for code breakage, since if a parameter name is changed, code will break regardless of what order the arguments are passed in.
>> 
>> If there's some other difference I'm missing that puts DIP 1020 and Walter's proposal at greater risk of breaking code than C#'s named arguments, I'd appreciate if you could point it out explicitly, since I am probably not the only one to have overlooked it.
>
> "No breaking changes are expected except in the case that any codebase declares an existing UDA called named."
>
> I do not expect code breakage to occur in either case.
> But I am concerned about the possibility and would prefer to design a little defensively (a few things like is expression handling for templates could break code if it was designed in a different way in DIP 1020).

I think you've misunderstood what 12345swordy and I are saying. The concern is not that DIP 1020 (or any other implementation of named arguments) will cause breakage *itself*, but that making parameter names part of a function's public interface could lead indirectly to *future* code breakage if any of those names are changed.

12345swordy's point #3 was that the above concern is, in his opinion, overblown, and that therefore we shouldn't bother requiring a @named attribute on parameters to address it. Personally, I share this opinion; my own experience in Python (which handles named arguments similarly to C#) is that parameter-name changes are not a problem in practice.

On Tuesday, 10 September 2019 at 14:19:02 UTC, rikki cattermole wrote:
> On 11/09/2019 2:01 AM, 12345swordy wrote:
>> Issues with the "@named" attribute:
>> 1.This is opt-in rather then opt-out, which may causes users to beg the library maintainers to update their libraries to support name attribute.
>
> This is intended.
> If you want to override the intention of the API author then we need to find another solution. One which I am unsure about how good it would be.

Make it an opt-in compiler flag.

Alex

On 11/09/2019 3:37 AM, Paul Backus wrote:
> I think you've misunderstood what 12345swordy and I are saying. The concern is not that DIP 1020 (or any other implementation of named arguments) will cause breakage *itself*, but that making parameter names part of a function's public interface could lead indirectly to *future* code breakage if any of those names are changed.
> 
> 12345swordy's point #3 was that the above concern is, in his opinion, overblown, and that therefore we shouldn't bother requiring a @named attribute on parameters to address it. Personally, I share this opinion; my own experience in Python (which handles named arguments similarly to C#) is that parameter-name changes are not a problem in practice.

Oh okay in that case, I do agree with both of you that potential breakage for name changes is over blown.

However DIP 1020 is opt-in and that design decision permeates throughout the entire DIP. Unlike syntax, I cannot change this without recreating the DIP from scratch.

To me named arguments work best when the API author is the one who made the decision to make it named. Not the API user. Ada and Python are both good examples of opt-in named arguments made by the API author.

Ultimately D is a production language.
Adding a language feature like named arguments so late could end badly if it intends to add new patterns of code that do not have solid examples in many existing code bases.

On 11/09/2019 3:45 AM, 12345swordy wrote:
> On Tuesday, 10 September 2019 at 14:19:02 UTC, rikki cattermole wrote:
>> On 11/09/2019 2:01 AM, 12345swordy wrote:
>>> Issues with the "@named" attribute:
>>> 1.This is opt-in rather then opt-out, which may causes users to beg the library maintainers to update their libraries to support name attribute.
>>
>> This is intended.
>> If you want to override the intention of the API author then we need to find another solution. One which I am unsure about how good it would be.
> 
> Make it an opt-in compiler flag.
> 
> Alex

I do not believe a flag like this is a good solution.
Over the years there has been a lot of talk about how bad -property is and it is similar in function to what you are proposing.

However I do have a syntax in mind if there is an overwhelming call to support overriding the API makers intention for an API.

The problem with it is, I have no idea how it would be implemented. But Walter seems to, so if the desire is there by enough people I guess I would have to add it.

I do think we would regret it, but at least with the syntax I'm thinking of it would be easy to remove should I turn out to be correct ( ``!Identifier:`` ).

I scribbled down a few points as I was reading through the DIP

1.

> Parameters must be marked as accepting named arguments, otherwise there will be no way to determine which overload to resolve.

I am little confused by this statement. Since later in the document you state that "Named parameters must not modify symbol or overload resolution", that means whether a argument is marked or not should have no impact on overload resolution?

2.

> named parameters must be opt-in.

Then all the argument against DIP1019's opt-in-ness also applies to this DIP.

3.

> Each named parameter must be marked

Can you discuss the pros and cons of marking each individual parameter vs marking functions?

4.

> The first addition is the isNamedParameter trait

Why couldn't we use getAttributes for this?

5.

> Overload resolution for symbols (for function and template declarations) is performed without taking named parameters into account

Ah, I guess this answers point (1). But this also means named parameters _does_ affect overload resolution, since functions with/without named parameters will be evaluated differently during overload resolution.

Also, I assume this is needed because you want to support reordering?

6.

> alias Bar2 = Bar!(int, Flag: 0); // error: matches both declarations

I think this has the potential to cause a lot of confusion.

7.

> Template declarations that have named parameters expose the named parameter as a member of the template.

Ah, this is very nice.


---

Also, thanks for pushing named arguments forward!

On 11/09/2019 4:39 AM, Yuxuan Shui wrote:
> I scribbled down a few points as I was reading through the DIP
> 
> 1.
> 
>> Parameters must be marked as accepting named arguments, otherwise there will be no way to determine which overload to resolve.
> 
> I am little confused by this statement. Since later in the document you state that "Named parameters must not modify symbol or overload resolution", that means whether a argument is marked or not should have no impact on overload resolution?
> 
> 2.
> 
>> named parameters must be opt-in.
> 
> Then all the argument against DIP1019's opt-in-ness also applies to this DIP.

Yes it does, but it buys you a lot more functionality compared to DIP1019.

> 3.
> 
>> Each named parameter must be marked
> 
> Can you discuss the pros and cons of marking each individual parameter vs marking functions?

Added: https://gist.github.com/rikkimax/91d0291da30d6ed161c6d3fa89868883

Typically you want to mix naming parameters and unnamed.
They are complimentary of each other.

E.g.

void func(int[] args..., @named bool flag);
func(1, 2, flag: false); // ok

A concrete example got removed during editing since this covers it but:

EmailStatus isEmail(Char)(const(Char)[] email, CheckDns checkDNS = No.checkDns, EmailStatusCode errorLevel = EmailStatusCode.none)

is a good example (checkDns and errorLevel could be named parameters) from https://dlang.org/phobos/std_net_isemail.html#.isEmail

> 4.
> 
>> The first addition is the isNamedParameter trait
> 
> Why couldn't we use getAttributes for this?

That is for UDA's and does not support function parameters.

isNamedParameter is modeled after an existing trait and will be used almost identically to it.

> 5.
> 
>> Overload resolution for symbols (for function and template declarations) is performed without taking named parameters into account
> 
> Ah, I guess this answers point (1). But this also means named parameters _does_ affect overload resolution, since functions with/without named parameters will be evaluated differently during overload resolution.

It depends on your perspective I guess.

See point 6 for example.
Basically the existing algorithms continue to do the same thing as they do now and ignore the new argument/parameter type.

> Also, I assume this is needed because you want to support reordering?
> 
> 6.
> 
>> alias Bar2 = Bar!(int, Flag: 0); // error: matches both declarations
> 
> I think this has the potential to cause a lot of confusion.

struct Bar(T) {
}

is the same as

struct Bar(T, @named int Flag) {
}

When doing symbol resolution (since the named parameter isn't accounted for, only verified after symbol/overload was chosen).

> 7.
> 
>> Template declarations that have named parameters expose the named parameter as a member of the template.
> 
> Ah, this is very nice.

Thanks!

wt., 10 wrz 2019 o 18:05 rikki cattermole via Digitalmars-d <digitalmars-d@puremagic.com> napisał(a):
>
> To me named arguments work best when the API author is the one who made the decision to make it named. Not the API user. Ada and Python are both good examples of opt-in named arguments made by the API author.

Don't know about Ada, but in Python arguments by default are both positional and named, You can make them named only or positional only, but positional only syntax is available from Python 3.8 (currently beta), before 3.8 there were no way to make arguments positional only except by writing function in C, or abusing vararg syntax.

On Tuesday, 10 September 2019 at 09:06:23 UTC, Mike Parker wrote:
> This is the feedback thread for the second round of Community Review for DIP 1020, "Named Parameters":
>
> https://github.com/dlang/DIPs/blob/c723d8f4e3ac2d5bcaf8cdff87e1507f09669ca6/DIPs/DIP1020.md

Summary of review: in general, this DIP should do a better job of explaining the reasoning behind its choices of syntax and semantics, especially in cases where clear alternatives were available. Pros and cons should be explicitly discussed, ideally with examples to illustrate them.

Detailed comments follow.

> Prior Work
>
> Dyalect

Why does the DIP include some random programmer's personal hobby language alongside ones with significant adoption like C# and Swift? Is it just to give an example of C#'s syntax with a different reordering rule? If so, isn't the fact that you couldn't find a mainstream example of this reordering rule evidence against considering it?

> Python
>
> [...]
> Parameter syntax: ** Identifier

This is inaccurate, or at least incomplete. All function parameters in Python can be passed by name; no special parameter syntax is required to enable named arguments. The syntax `** Identifier` (usually written `**kwargs`) is used specifically for *variadic* keyword arguments.

> Parameters must be marked as accepting named arguments, otherwise there will
> be no way to determine which overload to resolve.

The DIP needs to explain why this is true, not just assert it. At the very least, it should give an example of a function call for which overload resolution would fail if named parameters were not explicitly marked.

> It is the author's opinion that the is expression is heavily overloaded and
> doing too much. It should be possible to access the names of named template
> parameters outside of an instantiated template, but it should be done with a
> mechanism other than the is expression.

Personal opinion is an extremely weak justification, and unlikely to convince anyone who does not already agree with the DIP's author. This section would be much more convincing if it compared and contrasted both approaches, and listed the pros and cons of each.

> The @named attribute prevents clashes with other existing language features
> like template specializations (e.g., T:V or T=int). It aims to be opt-in
> rather than opt-out to prevent clashes with core semantics of the D
> programming language like function overloading.

The DIP should give specific examples of these "clashes" and explain how @named prevents them, rather than speaking in vague, general terms.

> The order of evaluation of named function arguments follows the lexical order
> of the argument list (full, not subset).

What does "(full, not subset)" mean? This is the only usage of the word "subset" in the entire DIP. The DIP should define any new terms it intends to use, rather than assume that the reader will infer the correct meaning from context.

> Two new traits are added to support type inspection. The first addition is
> the isNamedParameter trait, which allows a given parameter from the parameter
> list of a function, delegate, or a function pointer to be inspected for the
> presence of the @named attribute. This is intended to be used with the
> __parameters specialization of the is expression. The second addition is the
> getNamedParameters trait, which returns a list of all named parameters from
> the parameter list of a given template, function, delegate, or function
> pointer.

Why not have isNamedParameter work for templates too, and get rid of getNamedParameters?

> Overload resolution for symbols (for function and template declarations) is
> performed without taking named parameters into account. Ignoring named
> parameters in both cases means that the relevant algorithms and user code
> does not need to change to accommodate named parameters but they must be
> modified to filter them out. This is in line with the current behavior. A
> side effect of this is that name mangling does not need to change to
> accommodate these new parameters.
>
> [...]
>
>     void foo(int a) {
>     }
>
>     void foo(int a, @named int b) {
>     }
>
> [...]
>
>     foo(1); // error: matches both declarations
>     foo(1, b: 2); // error: matches both declarations

Given that the function calls are unambiguous as written, it seems very strange for the compiler to reject them. The DIP should explain, preferably with examples, what problems would be caused by allowing the compiler to accept these calls--i.e., what "algorithms and user code" would need to be changed, and how burdensome those changes would be.

> Template declarations that have named parameters expose the named parameter as a member of the template.

This feature is not essential to the DIP, so its inclusion needs to be justified separately.

> Manifest constant templates and templated aliases are treated as if they were
> eponymous templates and do expose named parameters as members.

Non-eponymous members of eponymous templates are currently inaccessible from outside the template body, so this will require changes to D's name lookup rules. Example:

   template size(T_)
   {
       alias T = T_;
       enum size = T_.sizeof;
   }

   // Error: no property T for type ulong
   pragma(msg, size!int.T);

> * named arguments at the end of an argument list may appear in any order
>
> * named arguments may be interleaved with positional arguments out of
> sequence, but if there are more than one they must match the order in which
> the named parameters are declared

The DIP should explain why these particular reordering rules were chosen instead of any of the alternatives from previous proposals, or from the examples given in the "Prior Work" section.

On Tuesday, 10 September 2019 at 16:09:39 UTC, rikki cattermole wrote:
> On 11/09/2019 3:45 AM, 12345swordy wrote:
>> On Tuesday, 10 September 2019 at 14:19:02 UTC, rikki cattermole wrote:
>>> On 11/09/2019 2:01 AM, 12345swordy wrote:
>>>> Issues with the "@named" attribute:
>>>> 1.This is opt-in rather then opt-out, which may causes users to beg the library maintainers to update their libraries to support name attribute.
>>>
>>> This is intended.
>>> If you want to override the intention of the API author then we need to find another solution. One which I am unsure about how good it would be.
>> 
>> Make it an opt-in compiler flag.
>> 
>> Alex
>
> I do not believe a flag like this is a good solution.
> Over the years there has been a lot of talk about how bad -property is and it is similar in function to what you are proposing.

The issue with property atm, is that is half-baked. People keep thinking that optional parentheses will replace it. It didn't as it doesn't support operators such as += and ++. This flag deals with the interaction with other libraries and public interfaces.


> However I do have a syntax in mind if there is an overwhelming call to support overriding the API makers intention for an API.
>
> The problem with it is, I have no idea how it would be implemented. But Walter seems to, so if the desire is there by enough people I guess I would have to add it.

Would it be better to have the named arguments opt-out via @unnamed instead of opt-in via @named? If certain people are that worry about breaking the public API, they should avoid mark their function as "@unnamed", instead having to mark every function @named just to use named arguments.

Besides we are dealing with c and c++ external bindings, and there are tools that generate those bindings. If I were to modify the tools to generate the @named arguments automatically, I still may end up in a plausable situation where the c/c++ library managers may changed the arguments names, which then causes breakage in the public api. Which it renders the case for @named moot, as you are not necessarily the developer for those c/c++ libraries.

This dip fail to provide a solid case where breakage from the change of the public api function arguments is a huge deal that needs to be avoided.

- Alex

On Tuesday, 10 September 2019 at 18:11:58 UTC, 12345swordy wrote:
> On Tuesday, 10 September 2019 at 16:09:39 UTC, rikki cattermole wrote:
>> On 11/09/2019 3:45 AM, 12345swordy wrote:
>>> On Tuesday, 10 September 2019 at 14:19:02 UTC, rikki cattermole wrote:
>>>> On 11/09/2019 2:01 AM, 12345swordy wrote:
>>>>> Issues with the "@named" attribute:
>>>>> 1.This is opt-in rather then opt-out, which may causes users to beg the library maintainers to update their libraries to support name attribute.
>>>>
>>>> This is intended.
>>>> If you want to override the intention of the API author then we need to find another solution. One which I am unsure about how good it would be.
>>> 
>>> Make it an opt-in compiler flag.
>>> 
>>> Alex
>>
>> I do not believe a flag like this is a good solution.
>> Over the years there has been a lot of talk about how bad -property is and it is similar in function to what you are proposing.
>
> The issue with property atm, is that is half-baked. People keep thinking that optional parentheses will replace it. It didn't as it doesn't support operators such as += and ++. This flag deals with the interaction with other libraries and public interfaces.
>
>
>> However I do have a syntax in mind if there is an overwhelming call to support overriding the API makers intention for an API.
>>
>> The problem with it is, I have no idea how it would be implemented. But Walter seems to, so if the desire is there by enough people I guess I would have to add it.
>
> Would it be better to have the named arguments opt-out via @unnamed instead of opt-in via @named? If certain people are that worry about breaking the public API, they should avoid mark their function as "@unnamed", instead having to mark every function @named just to use named arguments.
>
> Besides we are dealing with c and c++ external bindings, and there are tools that generate those bindings. If I were to modify the tools to generate the @named arguments automatically, I still may end up in a plausable situation where the c/c++ library managers may changed the arguments names, which then causes breakage in the public api. Which it renders the case for @named moot, as you are not necessarily the developer for those c/c++ libraries.
>
> This dip fail to provide a solid case where breakage from the change of the public api function arguments is a huge deal that needs to be avoided.
>
> - Alex

*they should mark their function as "@unnamed"

sorry mentally exhausted.