www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP 1020--Named Parameters--Community Review Round 2

reply Mike Parker <aldacron gmail.com> writes:
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

All review-related feedback on and discussion of the DIP should 
occur in this thread. The review period will end at 11:59 PM ET 
on September 24, or when I make a post declaring it complete.

At the end of Round 2, if further review is deemed necessary, the 
DIP will be scheduled for another round of Community Review. 
Otherwise, it will be queued for the Final Review and Formal 
Assessment.

Anyone intending to post feedback in this thread is expected to 
be familiar with the reviewer guidelines:

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

*Please stay on topic!*

Thanks in advance to all who participate.
Sep 10 2019
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/10/2019 2:06 AM, 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


For reference here's the round 1 thread:

https://digitalmars.com/d/archives/digitalmars/D/DIP_1020--Named_Parameters--Community_Review_Round_1_325299.html
Sep 10 2019
prev sibling next sibling parent reply SashaGreat <s g.com> writes:
Different options for opt-in named parameter syntax have been 
proposed and discussed in the D programming language community. 
DIP 88 proposed a colon to denote a named parameter, DIP 1019 
originally proposed the use of the  named function attribute, 
and this DIP originally proposed that angle brackets be used to 
denote named parameters. After feedback from the first round of 
review, this DIP has been amended to propose an new  named 
attribute with which to annotate parameters rather than 
functions.



struct Map( named alias Function,  named InputType,  named 
ElementType)



excessively noise in contrast.

Wouldn't be easier to go with Opt-Out (Or In) with a flag on 
Compiler level?

S.
Sep 10 2019
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 10/09/2019 11:51 PM, SashaGreat wrote:

 Different options for opt-in named parameter syntax have been proposed 
 and discussed in the D programming language community. DIP 88 proposed 
 a colon to denote a named parameter, DIP 1019 originally proposed the 
 use of the  named function attribute, and this DIP originally proposed 
 that angle brackets be used to denote named parameters. After feedback 
 from the first round of review, this DIP has been amended to propose 
 an new  named attribute with which to annotate parameters rather than 
 functions.


 

 struct Map( named alias Function,  named InputType,  named ElementType)


 

 in contrast.
 
 Wouldn't be easier to go with Opt-Out (Or In) with a flag on Compiler 
 level?
 
 S.


That would require a different design and I am not sure that it would be 
a good design element to incorporate.

I am happy to consider other options ( named was an option that was 
proposed in CR 1 that got a bit of support), however I am unsure if 
there is a better design waiting to be discovered.



In the example you referenced, the example in question over uses named 
parameters imo, for the purposes of demonstrating what it is capable of.

If that was a real example it should look somewhat like:

```
auto map(alias Function, InputType)(InputType input) {
	return Map!(Function, InputType)(input);
}

struct Map(alias Function, InputType,
	 named ElementType = ElementType!InputType)
```

Actionable list with this example listed on it is available here: 
https://gist.github.com/rikkimax/91d0291da30d6ed161c6d3fa89868883
Sep 10 2019
parent reply a11e99z <black80 bk.ru> writes:
On Tuesday, 10 September 2019 at 12:37:27 UTC, rikki cattermole 
wrote:

 On 10/09/2019 11:51 PM, SashaGreat wrote:


I have addition:

 named("arg") should accept string as named param name:
when arg is absent - use real param name
when arg is exists - use "arg" as param name for named param 
(phew!)

void func(  named("longBeautyName") int val ) {
   // I can use "val" here
   someGlobal = val;
}

// but when u use named param u should set longBeautyName
func( longBeautyName: 123 );
Sep 10 2019
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 11/09/2019 1:27 AM, a11e99z wrote:

 On Tuesday, 10 September 2019 at 12:37:27 UTC, rikki cattermole wrote:

 On 10/09/2019 11:51 PM, SashaGreat wrote:


 
 I have addition:
 
  named("arg") should accept string as named param name:
 when arg is absent - use real param name
 when arg is exists - use "arg" as param name for named param (phew!)
 
 void func(  named("longBeautyName") int val ) {
    // I can use "val" here
    someGlobal = val;
 }
 
 // but when u use named param u should set longBeautyName
 func( longBeautyName: 123 );


I quite like the syntax for this semantic.

However I am unsure of its beneficial nature.

This semantic would cover renaming and give greater freedom to the API 
creator, but it would require some changes that complicates 
introspection even in the most basic of use cases.

Once function bodies are removed (.di files), these renames wouldn't 
matter. You can just call the parameter whatever you want.

I am unsure how it would effect the arguments passing since I am not 
defining that (should be left to a compiler writer to decide that, 
either here or during implementation).

There is an alternative to this proposal which I prefer and that is to 
allow implicit construction of structs (with constructor defined to 
support passed in type). That would handle both deprecated names and 
types more uniformly but that would require another DIP.
Sep 10 2019
prev sibling next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
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

 All review-related feedback on and discussion of the DIP should 
 occur in this thread. The review period will end at 11:59 PM ET 
 on September 24, or when I make a post declaring it complete.

 At the end of Round 2, if further review is deemed necessary, 
 the DIP will be scheduled for another round of Community 
 Review. Otherwise, it will be queued for the Final Review and 
 Formal Assessment.

 Anyone intending to post feedback in this thread is expected to 
 be familiar with the reviewer guidelines:

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

 *Please stay on topic!*

 Thanks in advance to all who participate.


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.
2. Way too much verbiage for declaring functions with named 
arguments.
3.I still think the code breakage caused by named arguments is 

about code breakage regarding named arguments.

Most importantly, there should be a alternative solution section 
detailing Walter suggestion regarding named arguments. It be a 
total waste to not mention his solution given that it has shown 
support from other people.
Sep 10 2019
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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.


 2. Way too much verbiage for declaring functions with named arguments.
 3.I still think the code breakage caused by named arguments is still 

 breakage regarding named arguments.



conservative than both mine and Walter's.

That may have been a key factor in it not breaking peoples code.

D is a much more complex programming language and almost all talk of 
named arguments is nonrestrictive in nature. So I disagree with the 
statement that it is overblown, because it may very well be well founded.


 Most importantly, there should be a alternative solution section 
 detailing Walter suggestion regarding named arguments. It be a total 
 waste to not mention his solution given that it has shown support from 
 other people.


Agreed.

However I am unsure how to add it to the DIP as it is technically not 
prior work (since as far as I know it did not exist before DIP 1020 was 
created).

But that is a problem for me to solve at another time.

For reference, there is an example in the DIP related to parameter lists 
length that IMHO invalidates his proposal. But that is not stated hence 
some work has to be done on it at a later point.
Sep 10 2019
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
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 

 complains about code breakage regarding named arguments.



 importantly more conservative than both mine and Walter's.

 That may have been a key factor in it not breaking peoples code.



only difference I can find (leaving aside the parts about 

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 

named arguments, I'd appreciate if you could point it out 
explicitly, since I am probably not the only one to have 
overlooked it.
Sep 10 2019
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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 

 code breakage regarding named arguments.



 more conservative than both mine and Walter's.

 That may have been a key factor in it not breaking peoples code.


 

 difference I can find (leaving aside the parts about templates) is that 

 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 

 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).
Sep 10 2019
parent reply Paul Backus <snarwin gmail.com> writes:
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 

 complains about code breakage regarding named arguments.



 importantly more conservative than both mine and Walter's.

 That may have been a key factor in it not breaking peoples 
 code.


 

 the only difference I can find (leaving aside the parts about 

 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 

 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.


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 

parameter-name changes are not a problem in practice.
Sep 10 2019
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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.
 

 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 



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.
Sep 10 2019
parent Piotr Duda <duda.piotr gmail.com> writes:
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.
Sep 10 2019
prev sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
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
Sep 10 2019
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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:`` ).
Sep 10 2019
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
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
Sep 10 2019
next sibling parent 12345swordy <alexanderheistermann gmail.com> writes:
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.
Sep 10 2019
prev sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 11/09/2019 6:11 AM, 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.


I remain against it. However I will think about what you are saying with 
the flag. Even if I think the syntax ``! Identifier :`` to match against 
both named and unnamed parameters would cover you instead better.


 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.


Positional should remain the default (otherwise you risk changing how 
existing code gets thought about).

Anyway, I doubt anyone would use such an attribute.

I see named arguments used sparingly when the abstractions need it. I 
would question any code that used named parameters so heavily as to have 
them on every single parameter in quite large files.


 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 does not limit named parameters to extern(D) code. Since there 
may be valid reasons to need to extern(C) it within a code base.

But I do not intend for this feature to be used with other languages. 
Since their API authors you are binding to could not intend for their 
API to work with it.


 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


Actually right now I think DIP 1020 has the potential to have breakage 
from the change of API named parameter names. It alone provides no tools 
to deal with it.

Apart from designing a little defensively, I am not taking a stance on 
this problem in the DIP. But I think I should consider what you are 
saying. I think there is something I should take note of here but I'm 
not sure what it is just yet.
Sep 10 2019
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 10 September 2019 at 18:41:50 UTC, rikki cattermole 
wrote:

 [snip]

 Actually right now I think DIP 1020 has the potential to have 
 breakage from the change of API named parameter names. It alone 
 provides no tools to deal with it.

 Apart from designing a little defensively, I am not taking a 
 stance on this problem in the DIP. But I think I should 
 consider what you are saying. I think there is something I 
 should take note of here but I'm not sure what it is just yet.



I would think that this issue would affect any named parameter 
DIP. Library users would need to rely on the parameter names not 
changing if they make use of them. The most common tool would be 
grep. There's no reason that library authors couldn't use a 
deprecation period where they add another parameter to the 
function with the new name and have the old named one forward to 
it.

Also, the DIP has a section about the review and includes a 
mention to Walter's suggestion, but I don't really see an 
explanation of why this DIP is better than his suggestion. In 
general, I like the idea of named parameters, but I find his 
version more parsimonious until convinced otherwise.
Sep 10 2019
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 10 September 2019 at 20:08:38 UTC, jmh530 wrote:

 [snip]


I also don't understand this

void foo(int a) {
}

void foo(int a,  named int b) {
}

[snip]

foo(1); // error: matches both declarations
foo(1, b: 2); // error: matches both declarations
Sep 10 2019
parent Paul Backus <snarwin gmail.com> writes:
On Tuesday, 10 September 2019 at 20:33:01 UTC, jmh530 wrote:

 On Tuesday, 10 September 2019 at 20:08:38 UTC, jmh530 wrote:

 [snip]


 I also don't understand this

 void foo(int a) {
 }

 void foo(int a,  named int b) {
 }

 [snip]

 foo(1); // error: matches both declarations
 foo(1, b: 2); // error: matches both declarations


The idea is that named arguments and named parameters are ignored 
*completely* when resolving overloads--only the positional 
arguments are used. So it's as if you'd written:

void foo(int a) {
}

void foo(int a) {
}

foo(1);
foo(1);
Sep 10 2019
prev sibling next sibling parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
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!
Sep 10 2019
parent rikki cattermole <rikki cattermole.co.nz> writes:
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!
Sep 10 2019
prev sibling next sibling parent reply Paul Backus <snarwin gmail.com> writes:
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 


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.
Sep 10 2019
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 11/09/2019 5:30 AM, Paul Backus wrote:

 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/c723d8f4e3ac2d5bcaf8cdff87e1507f0966
ca6/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 


 rule? If so, isn't the fact that you couldn't find a mainstream example 
 of this reordering rule evidence against considering it?


Dyalect from what I understood support full reordering without any 
restrictions.
It was the first language I could find that had this.

Prior to editing revision 2 included full, partial and no reordering 
with pros and cons of each as options for voting upon.

It was an example of a language that supported full (most are partial, 
Swift/Objective-C is the closest to no reordering).


 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.


Noted for fixing.


 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.


The previous paragraph describes why you would want this. But I'll take 
note that it needs improving to make that clearer.


 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.


```d
void func() {
     alias Type = Foo!int;

     static if (is(Type : Foo!T, T)) {
     }
}

struct Foo(Type) {
}
```
	
If the template parameter of Foo was  named, then T in the static if 
would have to match the name of the parameter.
Which could conflict and the user would be forced to change other parts 
of the code and not use a name that suits them.
This is a consequence of named parameters being non-positional.

Sadly this change didn't make the cut for this revision.


 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.


This is a toughy.

Lets say we have a syntax derived from the argument syntax for parameters:

Type: Expression

becomes

Identifier : TemplateParameter

Which makes this valid:

T::V

but is T:V a named parameter with a name of T with invalid tokens after 
it or is it a template parameter with a name of T?

I will have to think about how to proceed, but I agree it needs improving.


 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.


I use sublist in the pseudo code of the resolution algorithm and subset 
here. The order was reversed when it was originally written. Noted.


 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?


How do you propose to get the names of the template parameters?

Unless there is some trick that I am unaware of that hasn't been added 
to std.traits, I do not believe that it would work. They are both needed.


 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.


There are two issues at play here.

1) Introspection of the function declaration
2) Function calling

Function calling is straight forward. Named parameters and hence named 
arguments are not taken into account with symbol/overload resolution. 
There is a requirements section dedicated to this.

Introspection is a lot more interesting. A good example of this is 
std.traits : isInstanceOf. And that is easily solved by using a string 
mixin to map the named parameters from T to S.

That is noted since that would be a good example of how simple it could 
potentially be. But I'm not sure I can do the opposite for complex 
(since then we are talking e.g. ORM's),
https://dlang.org/phobos/std_traits.html#.isInstanceOf


 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.


It is essential otherwise the DIP will need a full redesign.


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


Dangit, noted.


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


That means I need to add a new section and bring back some content from 
the pre-editing no/partial/full reordering sections about their pros/cons.


Actionable list available here: 
https://gist.github.com/rikkimax/91d0291da30d6ed161c6d3fa89868883

Thanks!
Sep 10 2019
prev sibling next sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
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

 All review-related feedback on and discussion of the DIP should 
 occur in this thread. The review period will end at 11:59 PM ET 
 on September 24, or when I make a post declaring it complete.

 At the end of Round 2, if further review is deemed necessary, 
 the DIP will be scheduled for another round of Community 
 Review. Otherwise, it will be queued for the Final Review and 
 Formal Assessment.

 Anyone intending to post feedback in this thread is expected to 
 be familiar with the reviewer guidelines:

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

 *Please stay on topic!*

 Thanks in advance to all who participate.


Sorry in advance for the bikeshedding, but using the   symbol 
just looks ugly to me. How about using 'public' instead of 
' named'?

     void foo( named bool log,  named bool goFast);
Vs.
     void foo(public bool log, public bool goFast);
Sep 10 2019
next sibling parent Max Haughton <maxhaton gmail.com> writes:
On Tuesday, 10 September 2019 at 18:47:54 UTC, Jonathan Marler 
wrote:

 On Tuesday, 10 September 2019 at 09:06:23 UTC, Mike Parker 
 wrote:

 [...]


 Sorry in advance for the bikeshedding, but using the   symbol 
 just looks ugly to me. How about using 'public' instead of 
 ' named'?

     void foo( named bool log,  named bool goFast);
 Vs.
     void foo(public bool log, public bool goFast);


I like that, both syntactically and also because the former would 
break anyone with UDAs called  named
Sep 10 2019
prev sibling next sibling parent reply Max Haughton <maxhaton gmail.com> writes:
On Tuesday, 10 September 2019 at 18:47:54 UTC, Jonathan Marler 
wrote:

 On Tuesday, 10 September 2019 at 09:06:23 UTC, Mike Parker 
 wrote:

 [...]


 Sorry in advance for the bikeshedding, but using the   symbol 
 just looks ugly to me. How about using 'public' instead of 
 ' named'?

     void foo( named bool log,  named bool goFast);
 Vs.
     void foo(public bool log, public bool goFast);


In fact,  public cannot compile as is so that might be a better 
solution still (bare "public" might require modifying the parser 
more but it's not my expertise)
Sep 10 2019
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Tuesday, 10 September 2019 at 19:34:45 UTC, Max Haughton wrote:

 On Tuesday, 10 September 2019 at 18:47:54 UTC, Jonathan Marler 
 wrote:

 On Tuesday, 10 September 2019 at 09:06:23 UTC, Mike Parker 
 wrote:

 [...]


 Sorry in advance for the bikeshedding, but using the   symbol 
 just looks ugly to me. How about using 'public' instead of 
 ' named'?

     void foo( named bool log,  named bool goFast);
 Vs.
     void foo(public bool log, public bool goFast);


 In fact,  public cannot compile as is so that might be a better 
 solution still (bare "public" might require modifying the 
 parser more but it's not my expertise)


Yes using `public` would require a grammar change.  However, the 
feature requires other grammar changes as well.  Also, using 
either `public` or ` named` without the feature will result in 
compilation errors so they're both on the same level in that 
regard.
Sep 10 2019
parent reply Max Haughton <maxhaton gmail.com> writes:
On Tuesday, 10 September 2019 at 19:50:44 UTC, Jonathan Marler 
wrote:

 On Tuesday, 10 September 2019 at 19:34:45 UTC, Max Haughton 
 wrote:

 On Tuesday, 10 September 2019 at 18:47:54 UTC, Jonathan Marler 
 wrote:

     [...]


 In fact,  public cannot compile as is so that might be a 
 better solution still (bare "public" might require modifying 
 the parser more but it's not my expertise)


 Yes using `public` would require a grammar change.  However, 
 the feature requires other grammar changes as well.  Also, 
 using either `public` or ` named` without the feature will 
 result in compilation errors so they're both on the same level 
 in that regard.


https://run.dlang.io/is/r409XD  named (on function parameters) 
compiles as of today
Sep 10 2019
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Tuesday, 10 September 2019 at 22:57:47 UTC, Max Haughton wrote:

 On Tuesday, 10 September 2019 at 19:50:44 UTC, Jonathan Marler 
 wrote:

 On Tuesday, 10 September 2019 at 19:34:45 UTC, Max Haughton 
 wrote:

 On Tuesday, 10 September 2019 at 18:47:54 UTC, Jonathan 
 Marler wrote:

     [...]


 In fact,  public cannot compile as is so that might be a 
 better solution still (bare "public" might require modifying 
 the parser more but it's not my expertise)


 Yes using `public` would require a grammar change.  However, 
 the feature requires other grammar changes as well.  Also, 
 using either `public` or ` named` without the feature will 
 result in compilation errors so they're both on the same level 
 in that regard.


 https://run.dlang.io/is/r409XD  named (on function parameters) 
 compiles as of today


You had to define the 'named' symbol. Which means if you compiled 
a module using it, it wouldn't compile because named wouldn't be 
defined.
Sep 10 2019
parent Max Haughton <maxhaton gmail.com> writes:
On Tuesday, 10 September 2019 at 23:57:33 UTC, Jonathan Marler 
wrote:

 On Tuesday, 10 September 2019 at 22:57:47 UTC, Max Haughton 
 wrote:

 On Tuesday, 10 September 2019 at 19:50:44 UTC, Jonathan Marler 
 wrote:

 On Tuesday, 10 September 2019 at 19:34:45 UTC, Max Haughton 
 wrote:

 [...]


 Yes using `public` would require a grammar change.  However, 
 the feature requires other grammar changes as well.  Also, 
 using either `public` or ` named` without the feature will 
 result in compilation errors so they're both on the same 
 level in that regard.


 https://run.dlang.io/is/r409XD  named (on function parameters) 
 compiles as of today


 You had to define the 'named' symbol. Which means if you 
 compiled a module using it, it wouldn't compile because named 
 wouldn't be defined.


I have used a UDA called named before. Using  named in the final 
DIP would break code for no reason
Sep 10 2019
prev sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 11/09/2019 6:47 AM, Jonathan Marler wrote:

 Sorry in advance for the bikeshedding, but using the   symbol just looks 
 ugly to me. How about using 'public' instead of ' named'?
 
      void foo( named bool log,  named bool goFast);
 Vs.
      void foo(public bool log, public bool goFast);


I considered this quite some time ago.

It works for templates, but it does not work for functions.

I have also considered  property, which would also look ok for templates 
and functions but would be rather long.

Right now  named is the best of possible syntaxes given the semantics 
which have been proposed IMHO.
Sep 10 2019
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Wednesday, 11 September 2019 at 05:15:04 UTC, rikki cattermole 
wrote:

 On 11/09/2019 6:47 AM, Jonathan Marler wrote:

 Sorry in advance for the bikeshedding, but using the   symbol 
 just looks ugly to me. How about using 'public' instead of 
 ' named'?
 
      void foo( named bool log,  named bool goFast);
 Vs.
      void foo(public bool log, public bool goFast);


 I considered this quite some time ago.

 It works for templates, but it does not work for functions.


Why wouldn't it work for functions?
Sep 11 2019
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 12/09/2019 4:08 AM, Jonathan Marler wrote:

 On Wednesday, 11 September 2019 at 05:15:04 UTC, rikki cattermole wrote:

 On 11/09/2019 6:47 AM, Jonathan Marler wrote:

 Sorry in advance for the bikeshedding, but using the   symbol just 
 looks ugly to me. How about using 'public' instead of ' named'?

      void foo( named bool log,  named bool goFast);
 Vs.
      void foo(public bool log, public bool goFast);


 I considered this quite some time ago.

 It works for templates, but it does not work for functions.


 
 Why wouldn't it work for functions?


Syntactically and semantically there is no reason for it to not work.

It comes down to personal preference. To me it means that there is some 
sort of semantic associated with functions and their named parameters 
like there is with templates when there isn't.
Sep 11 2019
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/10/2019 2:06 AM, 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/c723d8f4e3ac2d5bcaf8cdff87e1507f0966
ca6/DIPs/DIP1020.md 


My review is the same as in the first round:

https://digitalmars.com/d/archives/digitalmars/D/DIP_1020--Named_Parameters--Community_Review_Round_1_325299.html#N325627

To which Rikki responded with:

"That solves function arguments, what is your proposal for templates?"

https://digitalmars.com/d/archives/digitalmars/D/DIP_1020--Named_Parameters--Community_Review_Round_1_325299.html#N325631
Sep 10 2019
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 11/09/2019 9:10 AM, Walter Bright wrote:

 On 9/10/2019 2:06 AM, 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/c723d8f4e3ac2d5bcaf8cdff87e1507f0966
ca6/DIPs/DIP1020.md 


 
 
 My review is the same as in the first round:
 
 https://digitalmars.com/d/archives/digitalmars/D/DIP_1020--Named_Parameters--Community_Review_Round_1
325299.html#N325627 
 
 
 To which Rikki responded with:
 
 "That solves function arguments, what is your proposal for templates?"
 
 https://digitalmars.com/d/archives/digitalmars/D/DIP_1020--Named_Parameters--Community_Review_Round_1
325299.html#N325631 


I stand by my question.
In your proposal there was no mention of template support.

You have since said what your strategy is for templates.

https://digitalmars.com/d/archives/digitalmars/D/DIP_1020--Named_Parameters--Community_Review_Round_1_325299.html#N325650



However I disagree with your rationale.

"Although this supports reordering, the real reason for naming is so one 
can have a function with a longish list of parameters, each with a 
reasonable default, and the user need only supply the arguments that 
matter for his use case. This is much more flexible than the current 
method of putting all the defaults at the end of the parameter list, and 
defaulting one means all the rest get defaulted."

This is a known code smell with a known solution: refactoring.

I will posit that if you have code that has long parameters lists often, 
either you have a lot of technical debt or you are writing code that 
lends itself to introducing technical debt often.

For me at least, when I have long parameter lists, they typically 
involve math and are called in about one or two places at most and quite 
importantly all done within the same module. I do not believe that this 
warrants a language feature in of itself but I can be convinced that 
there are problems that lend itself to long parameter lists that are 
often solved.

Manu has a very interesting story related to this. Involving rewriting a 
code base for the purposes of refactoring of the data abstractions and 
ending up with faster code on platforms that it was expected to be much 
slower on.
Sep 10 2019
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/10/2019 10:37 PM, rikki cattermole wrote:

 On 11/09/2019 9:10 AM, Walter Bright wrote:

 My review is the same as in the first round:

 https://digitalmars.com/d/archives/digitalmars/D/DIP_1020--Named_Parameters--Community_Review_Round_1
325299.html#N325627 
 To which Rikki responded with:
 "That solves function arguments, what is your proposal for templates?"
 https://digitalmars.com/d/archives/digitalmars/D/DIP_1020--Named_Parameters--Community_Review_Round_1
325299.html#N325631 


 
 I stand by my question.
 In your proposal there was no mention of template support.
 
 You have since


The same day.



 said what your strategy is for templates.
 
 https://digitalmars.com/d/archives/digitalmars/D/DIP_1020--Named_Parameters--Community_Review_Round_1
325299.html#N325650 


Which was simply "Same problem, same solution".



 However I disagree with your rationale.


My suggestion is the leading alternative to yours, and the DIP needs to address 
it. The DIP gives no rationale for why reordering is undesirable (a link to an 
argument is not enough), as that question will interminably come up, and needs 
to be solid. It needs to justify being different from the struct literal
syntax, 
because being different (and less capable) is almost guaranteed to be a source 
of problems. (In particular, struct literals and function calls cannot become a 
unified syntax, as they almost are today.)
Sep 11 2019
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 11/09/2019 7:01 PM, Walter Bright wrote:

 However I disagree with your rationale.


 
 My suggestion is the leading alternative to yours, and the DIP needs to 
 address it. The DIP gives no rationale for why reordering is undesirable 
 (a link to an argument is not enough), as that question will 
 interminably come up, and needs to be solid. It needs to justify being 
 different from the struct literal syntax, because being different (and 
 less capable) is almost guaranteed to be a source of problems. (In 


Agreed.


 particular, struct literals and function calls cannot become a unified 
 syntax, as they almost are today.)


Okay that I need to think about.

But I need to confirm with you before I do this, is this for the 
replacement of in place struct initialization syntax?

If so I want to solve that, but I need to ask you how you would want it 
done. Since it touches upon .init, it makes me a little concerned 
because of dragons.
Sep 11 2019
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/11/2019 12:18 AM, rikki cattermole wrote:

 But I need to confirm with you before I do this, is this for the replacement
of 
 in place struct initialization syntax?
 
 If so I want to solve that, but I need to ask you how you would want it done. 
 Since it touches upon .init, it makes me a little concerned because of dragons.


I'm planning to replace:

   struct S { int a, b; }

   S s = { 1, 2 };

with:

   S s = S(1, 2);

D is almost there already, but is missing the named parameter feature to go all 
the way.

I'm looking at other ways as well to unify and thereby simplify D.
Sep 11 2019
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 12/09/2019 11:01 AM, Walter Bright wrote:

 On 9/11/2019 12:18 AM, rikki cattermole wrote:

 But I need to confirm with you before I do this, is this for the 
 replacement of in place struct initialization syntax?

 If so I want to solve that, but I need to ask you how you would want 
 it done. Since it touches upon .init, it makes me a little concerned 
 because of dragons.


 
 I'm planning to replace:
 
    struct S { int a, b; }
 
    S s = { 1, 2 };
 
 with:
 
    S s = S(1, 2);
 
 D is almost there already, but is missing the named parameter feature to 
 go all the way.
 
 I'm looking at other ways as well to unify and thereby simplify D.


Okay so it is what I'm thinking.

I currently have three solutions to support in place struct 
initialization with DIP 1020.

I would like to know which direction you would like me to go.

1. Syntax magic
2. Generate a constructor (which bypasses restrictions)
3. Hope somebody else figures out how to do it, but state that it is 
supported

I'm currently leaning towards 2 but it would mean researching what 
restrictions are in place, why they are in place and make sure I'm not 
breaking anything in the type system.

We would end up having two constructors generated, if the default 
constructor is not  disabled or if no constructors are defined. I'm not 
sure which restriction (or both).

struct Foo {
	int x, y;

	// generated
	this( named int x = int.init,
		 named int y = int.init) {
		this.x = x;
		this.y = y;
	}

	// generated
	this(int x, int y=int.init) {
		this.x = x;
		this.y = y;
	}
}
Sep 12 2019
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/12/2019 12:09 AM, rikki cattermole wrote:

 I currently have three solutions to support in place struct initialization
with 
 DIP 1020.
 
 I would like to know which direction you would like me to go.


Just use the syntax I proposed for named parameters. The feature will be 
disabled if the struct has constructor(s) for it, as now.

Kinda nothing to it.
Sep 12 2019
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 12/09/2019 9:18 PM, Walter Bright wrote:

 On 9/12/2019 12:09 AM, rikki cattermole wrote:

 I currently have three solutions to support in place struct 
 initialization with DIP 1020.

 I would like to know which direction you would like me to go.


 
 Just use the syntax I proposed for named parameters. The feature will be 
 disabled if the struct has constructor(s) for it, as now.
 
 Kinda nothing to it.


Sweet, noted.
Sep 12 2019
prev sibling next sibling parent a11e99z <black80 bk.ru> writes:
On Wednesday, 11 September 2019 at 23:01:32 UTC, Walter Bright 
wrote:

 On 9/11/2019 12:18 AM, rikki cattermole wrote:

 But I need to confirm with you before I do this, is this for 
 the replacement of in place struct initialization syntax?
 
 If so I want to solve that, but I need to ask you how you 
 would want it done. Since it touches upon .init, it makes me a 
 little concerned because of dragons.


 I'm planning to replace:

   struct S { int a, b; }

   S s = { 1, 2 };


I don't like this style too.


   S s = S( a=1, b=2 );


with named args it will be more readable.

but more than this I want next:

 // dont need "new" cuz its not needed for structs
 // and not needed for classes too - they are in GC by default



 auto form = AppWindow {
     title = "main window",
     children = [ // child-list
       TextBox {
         text = "Hello World!",
         font = Font { family="Times Roman", height=24 },
       },
       Button {
         text = "Press me!",
         tilt = Color.Red,
         click ~= parent.close() // delegate list
       }
     ]
   };


probably it better to do not through constructor but with some 
kind of init-list:

 opAssignInitList( /* what here? tuple? */ ) = default;


that assign automatically to all fields and properties
and just check that no one field/prop assigned more than once
Sep 12 2019
prev sibling next sibling parent a11e99z <black80 bk.ru> writes:
On Wednesday, 11 September 2019 at 23:01:32 UTC, Walter Bright 
wrote:

 On 9/11/2019 12:18 AM, rikki cattermole wrote:

 But I need to confirm with you before I do this, is this for 
 the replacement of in place struct initialization syntax?
 
 If so I want to solve that, but I need to ask you how you 
 would want it done. Since it touches upon .init, it makes me a 
 little concerned because of dragons.


 I'm planning to replace:

   struct S { int a, b; }

   S s = { 1, 2 };


I don't like this style too.


   S s = S( a=1, b=2 );


with named args it will be more readable.

but more than this I want next:

 // dont need "new" cuz its not needed for structs
 // and not needed for classes too - they are in GC by default
 auto form = AppWindow {
     title = "main window",
     children = [ // child-list
       TextBox {
         text = "Hello World!",
         font = Font { family="Times Roman", height=24 },
       },
       Button {
         text = "Press me!",
         tilt = Color.Red,
         click ~= parent.close() // delegate list
       }
     ]
   };


probably it better to do not through constructor but with some 
kind of init-list:

 opAssignInitList( /* what here? tuple? */ ) = default;


that assign automatically to all fields and properties
and just check that no one field/prop assigned more than once
Sep 12 2019
prev sibling parent Andre Pany <andre s-e-a-p.de> writes:
On Wednesday, 11 September 2019 at 23:01:32 UTC, Walter Bright 
wrote:

 On 9/11/2019 12:18 AM, rikki cattermole wrote:

 But I need to confirm with you before I do this, is this for 
 the replacement of in place struct initialization syntax?
 
 If so I want to solve that, but I need to ask you how you 
 would want it done. Since it touches upon .init, it makes me a 
 little concerned because of dragons.


 I'm planning to replace:

   struct S { int a, b; }

   S s = { 1, 2 };

 with:

   S s = S(1, 2);

 D is almost there already, but is missing the named parameter 
 feature to go all the way.

 I'm looking at other ways as well to unify and thereby simplify 
 D.


While this solves some issues, I see one major drawback. This 
example looks currently very dense. With the new syntax it 
becomes more verbose because you have to name the structures:

struct PutItemRequest
{
     string tableName;
     AttributeValue[string] item;
}

struct AttributeValue
{
     bool BOOL;
     string S;
     AttributeValue[string] M;
     string[] SS;
}

void main()
{
     PutItemRequest request = {
	    tableName: "table1",
		item: [
		    "field1": {S: "LALA"},
			"field2": {SS: ["A", "B", "C"]},
			"field3": {
			    M: ["fieldA": {S: "234"}]
			}
		]
	};
}

This example is from the Amazon Web Services library I am using. 
It is rather small. Other calls uses more deep structures.

Also please note, it doesn't compile today because you can use 
struct initialization today only for arrays but not for 
associative arrays.

Kind regards
Andre
Sep 12 2019
prev sibling parent reply JN <666total wp.pl> writes:
On Wednesday, 11 September 2019 at 05:37:57 UTC, rikki cattermole 
wrote:

 This is a known code smell with a known solution: refactoring.

 I will posit that if you have code that has long parameters 
 lists often, either you have a lot of technical debt or you are 
 writing code that lends itself to introducing technical debt 
 often.

 For me at least, when I have long parameter lists, they 
 typically involve math and are called in about one or two 
 places at most and quite importantly all done within the same 
 module. I do not believe that this warrants a language feature 
 in of itself but I can be convinced that there are problems 
 that lend itself to long parameter lists that are often solved.


Long parameter lists usually aren't a code smell, and personal 
opinions and preferences are not enough to refute it. The 
alternative to long parameter lists is the Builder OOP pattern, 
which also usually isn't a code smell. Some records/objects just 
have many members and it doesn't make sense to split them up into 
smaller groups.
Sep 11 2019
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 11/09/2019 8:16 PM, JN wrote:

 On Wednesday, 11 September 2019 at 05:37:57 UTC, rikki cattermole wrote:

 This is a known code smell with a known solution: refactoring.

 I will posit that if you have code that has long parameters lists 
 often, either you have a lot of technical debt or you are writing code 
 that lends itself to introducing technical debt often.

 For me at least, when I have long parameter lists, they typically 
 involve math and are called in about one or two places at most and 
 quite importantly all done within the same module. I do not believe 
 that this warrants a language feature in of itself but I can be 
 convinced that there are problems that lend itself to long parameter 
 lists that are often solved.


 
 Long parameter lists usually aren't a code smell, and personal opinions 
 and preferences are not enough to refute it. The alternative to long 
 parameter lists is the Builder OOP pattern, which also usually isn't a 
 code smell. Some records/objects just have many members and it doesn't 
 make sense to split them up into smaller groups.


There are quite a few people who believe as I do that long parameter 
lists are a code smell or at the very least indicative that there 
probably is a problem with the data abstraction.

Maybe not convincing for part of a DIP (its not part of DIP 1020 after 
all), but I would hope that we can agree that this opinion is not 
limited to just a few people.



Chapter 24 of Code complete second edition: Reasons to refactor.

"Well-factored programs tend to have many small, well-defined routines 
that don't need large parameter lists. A long parameter list is a 
warning that the abstraction of the routine interface has not been well 
thought out."


The closest thing I can find in my writing solid code book for C is 
"Don't write multipurpose functions. Write separate functions to allow 
stronger argument validation." but I am not sure it applies (but it 
might do in some contexts).


https://stackoverflow.com/questions/439574/whats-the-best-way-to-refactor-a-method-that-has-too-many-6-parameters

http://www.tusharma.in/smells/LPL.html

https://medium.com/ KonfHub/refactoring-long-parameter-list-in-constructors-java-e9c9f2cb1fb
Sep 11 2019
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/10/19 5:10 PM, Walter Bright wrote:

 On 9/10/2019 2:06 AM, 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/c723d8f4e3ac2d5bcaf8cdff87e1507f0966
ca6/DIPs/DIP1020.md 


 
 
 My review is the same as in the first round:
 
 https://digitalmars.com/d/archives/digitalmars/D/DIP_1020--Named_Parameters--Community_Review_Round_1
325299.html#N325627 
 
 
 To which Rikki responded with:
 
 "That solves function arguments, what is your proposal for templates?"
 
 https://digitalmars.com/d/archives/digitalmars/D/DIP_1020--Named_Parameters--Community_Review_Round_1
325299.html#N325631 


Same here. Whoever wants to take Walter's proposal toward completion of 
a DIP would do a great service to the community.
Sep 12 2019
prev sibling next sibling parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
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


I can't seem to find the rationale for the necessity of a 
parameter syntax? As a library writer, when would I annotate a 
parameter with ` named`? Does adding ` named` *require* naming 
the parameter? The DIP notes a new trait to find named vs unnamed 
parameters, but is that the *reason* for the new syntax or a 
handy side effect? Couldn't the regular UDA trait be used (or 
extended) to find ` named` or any other UDA for that matter?

If I assume there's a good reason for having this opt-in for 
parameters, wouldn't this then require a lot of churn for library 
writers, with diffs adding just ` named` to parameters and no 
other code changes?

"The primary aim of this proposal is to aid in readability and 
the implementation of tooling."

This primary aim can be achieved with less syntax and rules:
* No new parameter syntax
* Make argument names optional using the proposed `Identifier : 
ConditionalExpression` syntax, with a compiler error on 
identifier mismatch

Mentioning argument names at the call site improves readability 
and code robustness. This doesn't allow reordering, but also 
avoids any expectation of overloading based on parameter names.

Lio.
Sep 10 2019
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 11/09/2019 5:53 PM, Lionello Lunesu wrote:

 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/c723d8f4e3ac2d5bcaf8cdff87e1507f0966
ca6/DIPs/DIP1020.md 


 
 I can't seem to find the rationale for the necessity of a parameter 
 syntax? As a library writer, when would I annotate a parameter with 
 ` named`? Does adding ` named` *require* naming the parameter? The DIP 
 notes a new trait to find named vs unnamed parameters, but is that the 
 *reason* for the new syntax or a handy side effect? Couldn't the regular 
 UDA trait be used (or extended) to find ` named` or any other UDA for 
 that matter?


A named parameter must include a name yes. Good catch.

The trait(s) is listed under "Supporting Syntax". It supports the rest 
of the DIP and while useful I wouldn't call it a handy side effect or a 
reason for design choices were made.

Its a simple way that does not require much in the way of changes to the 
language or would take very long to implement to get the named parameter 
names on a template (for e.g. functions that is a side effect for 
consistency reasons).


 If I assume there's a good reason for having this opt-in for parameters, 
 wouldn't this then require a lot of churn for library writers, with 
 diffs adding just ` named` to parameters and no other code changes?


Nobody is forced to use it.

I would recommend to incrementally add it, as the API designs allow for 
it, and not just add it because it exists.
Sep 11 2019
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Wednesday, 11 September 2019 at 14:33:37 UTC, rikki cattermole 
wrote:

 On 11/09/2019 5:53 PM, Lionello Lunesu wrote:

 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


 
 I can't seem to find the rationale for the necessity of a 
 parameter syntax? As a library writer, when would I annotate a 
 parameter with ` named`? Does adding ` named` *require* naming 
 the parameter? The DIP notes a new trait to find named vs 
 unnamed parameters, but is that the *reason* for the new 
 syntax or a handy side effect? Couldn't the regular UDA trait 
 be used (or extended) to find ` named` or any other UDA for 
 that matter?


 A named parameter must include a name yes. Good catch.

 The trait(s) is listed under "Supporting Syntax". It supports 
 the rest of the DIP and while useful I wouldn't call it a handy 
 side effect or a reason for design choices were made.

 Its a simple way that does not require much in the way of 
 changes to the language or would take very long to implement to 
 get the named parameter names on a template (for e.g. functions 
 that is a side effect for consistency reasons).


 If I assume there's a good reason for having this opt-in for 
 parameters, wouldn't this then require a lot of churn for 
 library writers, with diffs adding just ` named` to parameters 
 and no other code changes?


 Nobody is forced to use it.

 I would recommend to incrementally add it, as the API designs 
 allow for it, and not just add it because it exists.


What good is named arguments if around 90% libraries don't 
support it?
Sep 11 2019
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 12/09/2019 3:12 AM, 12345swordy wrote:

 What good is named arguments if around 90% libraries don't support it?


I won't put a percentage on the number of libraries that will not 
support it. Over time the number should decrease as people get use to it 
and find ways to use it to suit their style.
Sep 11 2019
next sibling parent 12345swordy <alexanderheistermann gmail.com> writes:
On Wednesday, 11 September 2019 at 16:00:13 UTC, rikki cattermole 
wrote:

 On 12/09/2019 3:12 AM, 12345swordy wrote:

 What good is named arguments if around 90% libraries don't 
 support it?


 I won't put a percentage on the number of libraries that will 
 not support it. Over time the number should decrease as people 
 get use to it and find ways to use it to suit their style.


That is an assertion, with no evidence. Your DIP needs to take 
the account of libraries that are hardly updated. Why should the 
user suffer when the libraries aren't updated or refused to 
update their functions with named arguments even when it seems 
very reasonable at the time to the user. You can't just suggest 
that the user to fork every library out there in order to used 
named arguments!

I repeat: This "public api" issue is overblown. This issue you 
try to avoid still will still exist even you did make it opt-in.

I can't advocate this with a straight face in game development.

-Alex
Sep 11 2019
prev sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Wednesday, 11 September 2019 at 16:00:13 UTC, rikki cattermole 
wrote:

 On 12/09/2019 3:12 AM, 12345swordy wrote:

 What good is named arguments if around 90% libraries don't 
 support it?


 I won't put a percentage on the number of libraries that will 
 not support it. Over time the number should decrease as people 
 get use to it and find ways to use it to suit their style.


Given that adding  named to an existing parameter would be a 
breaking change, it's unlikely any existing libraries--including 
existing Phobos modules--will be updated to support named 
arguments. Only new libraries written after DIP 1020 is 
implemented and released will be in a good position to take 
advantage of it.

This is a major downside to DIP 1020 compared to both Walter's 
proposal and DIP 1019 ("Named Arguments Lite"), which would work 
seamlessly with existing code.
Sep 11 2019
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 12/09/2019 4:57 AM, Paul Backus wrote:

 On Wednesday, 11 September 2019 at 16:00:13 UTC, rikki cattermole wrote:

 On 12/09/2019 3:12 AM, 12345swordy wrote:

 What good is named arguments if around 90% libraries don't support it?


 I won't put a percentage on the number of libraries that will not 
 support it. Over time the number should decrease as people get use to 
 it and find ways to use it to suit their style.


 
 Given that adding  named to an existing parameter would be a breaking 
 change, it's unlikely any existing libraries--including existing Phobos 
 modules--will be updated to support named arguments. Only new libraries 
 written after DIP 1020 is implemented and released will be in a good 
 position to take advantage of it.
 
 This is a major downside to DIP 1020 compared to both Walter's proposal 
 and DIP 1019 ("Named Arguments Lite"), which would work seamlessly with 
 existing code.


There is no reason to believe that Phobos cannot be updated nor other 
existing libraries.

Deprecate old prototype.

Add new prototype.

Old prototype calls new prototype.

No more Flag nonsense and will be fairly easy to implement.
Sep 12 2019
next sibling parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
On Thursday, 12 September 2019 at 09:17:54 UTC, rikki cattermole 
wrote:

 On 12/09/2019 4:57 AM, Paul Backus wrote:

 [...]


 There is no reason to believe that Phobos cannot be updated nor 
 other existing libraries.

 Deprecate old prototype.

 Add new prototype.

 Old prototype calls new prototype.


Does that essentially mean we are going to rename all the 
functions?


 No more Flag nonsense and will be fairly easy to implement.
Sep 12 2019
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 12/09/2019 11:25 PM, Yuxuan Shui wrote:

 On Thursday, 12 September 2019 at 09:17:54 UTC, rikki cattermole wrote:

 On 12/09/2019 4:57 AM, Paul Backus wrote:

 [...]


 There is no reason to believe that Phobos cannot be updated nor other 
 existing libraries.

 Deprecate old prototype.

 Add new prototype.

 Old prototype calls new prototype.


 
 Does that essentially mean we are going to rename all the functions?


Of course not.

Overloading of symbols is a great thing ;)

We only need to do it incrementally for functions/templates where it 
makes sense. Not everything would benefit from named parameters.

E.g.

void func(int something, int flag = 0)

becomes

deprecated("Use named arguments version")
void func(int something, int flag) {
	func(something, flag: flag);
}

void func(int something,  named int flag = 0)
Sep 12 2019
prev sibling parent 12345swordy <alexanderheistermann gmail.com> writes:
On Thursday, 12 September 2019 at 09:17:54 UTC, rikki cattermole 
wrote:

 On 12/09/2019 4:57 AM, Paul Backus wrote:
 There is no reason to believe that Phobos cannot be updated nor 
 other existing libraries.


The development of Phobos is slow as a snail pace, even when it 
comes to refactoring. Again we are talking about old libraries 
that backwards compatible and that are hardly updated. That will 
certainly will kill the adoption rate.

Alex
Sep 12 2019
prev sibling next sibling parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
Dumb question:  named parameters are ignored in overload 
resolution, so in this example:

void draw( named Circle shape);
void draw( named Rectangle shape);

Is a call to draw:

draw(someShape);

always going to be a compilation error?
Sep 12 2019
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 12/09/2019 11:29 PM, Yuxuan Shui wrote:

 Dumb question:  named parameters are ignored in overload resolution, so 
 in this example:
 
 void draw( named Circle shape);
 void draw( named Rectangle shape);
 
 Is a call to draw:
 
 draw(someShape);
 
 always going to be a compilation error?


Yes.

Because you didn't use a named argument.

These would have been valid declarations that would match that function 
call:

void draw(Circle shape);
void draw(Rectangle shape);

In this example you didn't need named parameters.
Since the variable name of the calling body should be descriptive enough 
to tell you that it is a circle/rectangle.
Sep 12 2019
next sibling parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
On Thursday, 12 September 2019 at 11:46:46 UTC, rikki cattermole 
wrote:

 On 12/09/2019 11:29 PM, Yuxuan Shui wrote:

 Dumb question:  named parameters are ignored in overload 
 resolution, so in this example:
 
 void draw( named Circle shape);
 void draw( named Rectangle shape);
 
 Is a call to draw:
 
 draw(someShape);
 
 always going to be a compilation error?


 Yes.

 Because you didn't use a named argument.

 These would have been valid declarations that would match that 
 function call:

 void draw(Circle shape);
 void draw(Rectangle shape);

 In this example you didn't need named parameters.
 Since the variable name of the calling body should be 
 descriptive enough to tell you that it is a circle/rectangle.


Ah, sorry. I meant to write draw(shape: someShape).
Sep 12 2019
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 12/09/2019 11:50 PM, Yuxuan Shui wrote:

 On Thursday, 12 September 2019 at 11:46:46 UTC, rikki cattermole wrote:

 On 12/09/2019 11:29 PM, Yuxuan Shui wrote:

 Dumb question:  named parameters are ignored in overload resolution, 
 so in this example:

 void draw( named Circle shape);
 void draw( named Rectangle shape);

 Is a call to draw:

 draw(someShape);

 always going to be a compilation error?


 Yes.

 Because you didn't use a named argument.

 These would have been valid declarations that would match that 
 function call:

 void draw(Circle shape);
 void draw(Rectangle shape);

 In this example you didn't need named parameters.
 Since the variable name of the calling body should be descriptive 
 enough to tell you that it is a circle/rectangle.


 
 Ah, sorry. I meant to write draw(shape: someShape).


In that case, two methods:

1. void draw(Shape)( named Shape shape) { draw(shape); }

2. void draw(Shape:Circle)( named Shape shape) { draw(shape); }

The second is better because of validating the parameter type, but does 
require one per type. Assuming I remember this particular bit of 
templates correctly.

I had to assume that drawing has to be specific to the type passed in 
and that the draw function will be concrete (can be virtual). But that 
shouldn't be a problem.
Sep 12 2019
parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
On Thursday, 12 September 2019 at 12:06:47 UTC, rikki cattermole 
wrote:

 On 12/09/2019 11:50 PM, Yuxuan Shui wrote:

 On Thursday, 12 September 2019 at 11:46:46 UTC, rikki 
 cattermole wrote:

 [...]


 
 Ah, sorry. I meant to write draw(shape: someShape).


 In that case, two methods:

 1. void draw(Shape)( named Shape shape) { draw(shape); }

 2. void draw(Shape:Circle)( named Shape shape) { draw(shape); }

 The second is better because of validating the parameter type, 
 but does require one per type. Assuming I remember this 
 particular bit of templates correctly.

 I had to assume that drawing has to be specific to the type 
 passed in and that the draw function will be concrete (can be 
 virtual). But that shouldn't be a problem.


Sorry, I don't think I understand your answer. My question has 
nothing to do with templates.
Sep 12 2019
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 13/09/2019 1:44 AM, Yuxuan Shui wrote:

 On Thursday, 12 September 2019 at 12:06:47 UTC, rikki cattermole wrote:

 On 12/09/2019 11:50 PM, Yuxuan Shui wrote:

 On Thursday, 12 September 2019 at 11:46:46 UTC, rikki cattermole wrote:

 [...]


 Ah, sorry. I meant to write draw(shape: someShape).


 In that case, two methods:

 1. void draw(Shape)( named Shape shape) { draw(shape); }

 2. void draw(Shape:Circle)( named Shape shape) { draw(shape); }

 The second is better because of validating the parameter type, but 
 does require one per type. Assuming I remember this particular bit of 
 templates correctly.

 I had to assume that drawing has to be specific to the type passed in 
 and that the draw function will be concrete (can be virtual). But that 
 shouldn't be a problem.


 
 Sorry, I don't think I understand your answer. My question has nothing 
 to do with templates.


To get the functionality you asked about, I had to use templates.

To support overloading on named parameters would require invasive 
changes and adding a new mangling sequence. Things I want to avoid.

a11e99z asked a similar question under your own in this part of the 
thread tree. Same answer.
Sep 12 2019
next sibling parent reply a11e99z <black80 bk.ru> writes:
On Thursday, 12 September 2019 at 14:36:09 UTC, rikki cattermole 
wrote:

 On 13/09/2019 1:44 AM, Yuxuan Shui wrote:

 On Thursday, 12 September 2019 at 12:06:47 UTC, rikki 
 cattermole wrote:

 On 12/09/2019 11:50 PM, Yuxuan Shui wrote:

 On Thursday, 12 September 2019 at 11:46:46 UTC, rikki 
 cattermole wrote:






 To support overloading on named parameters would require 
 invasive changes and adding a new mangling sequence. Things I 
 want to avoid.


I am not considering named template arguments now cuz me with 
templates is not like a fish in water.

 named will be only in source code or .di files.
how and why  named should be involved in mangled names and method 
selection?

why the following rules are bad:
- naming is not mandatory and
- method are selecting as usual by overload/UFCS rules and
   need to check that named args satisfy  named args in found func 
definition.
   in other case probably user thought about another function.

----------------------

sux.

do what u want.
but please don't add mandatory  named to functions that can be 
used in lambdas - map, fold, take, another hundred functions too. 
cuz it will be shitty named mess.
Sep 12 2019
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 13/09/2019 2:51 AM, a11e99z wrote:

 how and why  named should be involved in mangled names and method 
 selection?


They don't.
Sep 12 2019
prev sibling parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
On Thursday, 12 September 2019 at 14:36:09 UTC, rikki cattermole 
wrote:

 On 13/09/2019 1:44 AM, Yuxuan Shui wrote:

 On Thursday, 12 September 2019 at 12:06:47 UTC, rikki 
 cattermole wrote:

 On 12/09/2019 11:50 PM, Yuxuan Shui wrote:

 On Thursday, 12 September 2019 at 11:46:46 UTC, rikki 
 cattermole wrote:

 [...]


 Ah, sorry. I meant to write draw(shape: someShape).


 In that case, two methods:

 1. void draw(Shape)( named Shape shape) { draw(shape); }

 2. void draw(Shape:Circle)( named Shape shape) { draw(shape); 
 }

 The second is better because of validating the parameter 
 type, but does require one per type. Assuming I remember this 
 particular bit of templates correctly.

 I had to assume that drawing has to be specific to the type 
 passed in and that the draw function will be concrete (can be 
 virtual). But that shouldn't be a problem.


 
 Sorry, I don't think I understand your answer. My question has 
 nothing to do with templates.


 To get the functionality you asked about, I had to use 
 templates.

 To support overloading on named parameters would require 
 invasive changes and adding a new mangling sequence. Things I 
 want to avoid.

 a11e99z asked a similar question under your own in this part of 
 the thread tree. Same answer.


No, I am not asking for overloading based on name. The two 
functions are clearly distinct based purely on parameter types.

I think this basically means you cannot create functions with 
only  named parameters. I consider this a pretty serious 
limitation.
Sep 12 2019
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 13/09/2019 6:00 AM, Yuxuan Shui wrote:

 On Thursday, 12 September 2019 at 14:36:09 UTC, rikki cattermole wrote:

 On 13/09/2019 1:44 AM, Yuxuan Shui wrote:

 On Thursday, 12 September 2019 at 12:06:47 UTC, rikki cattermole wrote:

 On 12/09/2019 11:50 PM, Yuxuan Shui wrote:

 On Thursday, 12 September 2019 at 11:46:46 UTC, rikki cattermole 
 wrote:

 [...]


 Ah, sorry. I meant to write draw(shape: someShape).


 In that case, two methods:

 1. void draw(Shape)( named Shape shape) { draw(shape); }

 2. void draw(Shape:Circle)( named Shape shape) { draw(shape); }

 The second is better because of validating the parameter type, but 
 does require one per type. Assuming I remember this particular bit 
 of templates correctly.

 I had to assume that drawing has to be specific to the type passed 
 in and that the draw function will be concrete (can be virtual). But 
 that shouldn't be a problem.


 Sorry, I don't think I understand your answer. My question has 
 nothing to do with templates.


 To get the functionality you asked about, I had to use templates.

 To support overloading on named parameters would require invasive 
 changes and adding a new mangling sequence. Things I want to avoid.

 a11e99z asked a similar question under your own in this part of the 
 thread tree. Same answer.


 
 No, I am not asking for overloading based on name. The two functions are 
 clearly distinct based purely on parameter types.
 
 I think this basically means you cannot create functions with only 
  named parameters. I consider this a pretty serious limitation.


You can create functions with just  named parameters, but you can't use 
overloading with them.

Its a side effect of not touching symbol+overload resolution.

Keep in mind that the syntax:

void draw(Shape:Circle)( named Shape shape)

will allow you to have multiple functions named the same thing with 
 named parameters. So its not as serious as it may first seem IMO.
Sep 12 2019
prev sibling parent reply a11e99z <black80 bk.ru> writes:
On Thursday, 12 September 2019 at 11:46:46 UTC, rikki cattermole 
wrote:

 On 12/09/2019 11:29 PM, Yuxuan Shui wrote:

 Dumb question:  named parameters are ignored in overload 
 resolution, so in this example:
 
 void draw( named Circle shape);
 void draw( named Rectangle shape);
 
 Is a call to draw:
 
 draw(someShape);
 
 always going to be a compilation error?


 Yes.
 Because you didn't use a named argument.


wait!
why should be error here?
when named args doesn't set - use usual overload rules.


 void draw(  named Rect rect );
 void draw(  named Circle oval );



 Shape shape = Line( ... ); // can be Rect/Circle too with same 
 result
 Rect oval = Rect( ... );
 Circle rect = Circle( ... );



 draw( shape ); // ERROR. no method for Shape
 draw( rect ); // OK. draw( Circle <- rect ). rect is Circle in 
 my case
 draw( oval ); // OK. draw( Rect <- oval ).



 draw( oval: shape ); // ERROR: struct/class Shape is not good 
 for any overloads



 draw( oval: oval ); // ERROR: oval is Rect and no named arg 
 "oval" for method that receive Rect.



 draw( oval: rect ); // OK. draw( Circle <- rect )



 draw( rect: shape ); // ERROR. No overloads for Shape



 draw( rect: rect ); // ERROR. rect is Circle and method draw( 
 Circle ) doens't have arg "rect"



 draw( rect: oval ); // OK. draw( Rect <- oval );
Sep 12 2019
parent reply a11e99z <black80 bk.ru> writes:
On Thursday, 12 September 2019 at 12:15:57 UTC, a11e99z wrote:

 On Thursday, 12 September 2019 at 11:46:46 UTC, rikki 
 cattermole wrote:

 On 12/09/2019 11:29 PM, Yuxuan Shui wrote:




naming args is not mandatory.
using names depends from user of lib not from lib itself or 
compiler.
Sep 12 2019
next sibling parent a11e99z <black80 bk.ru> writes:
On Thursday, 12 September 2019 at 12:19:51 UTC, a11e99z wrote:

 On Thursday, 12 September 2019 at 12:15:57 UTC, a11e99z wrote:

 On Thursday, 12 September 2019 at 11:46:46 UTC, rikki 
 cattermole wrote:

 On 12/09/2019 11:29 PM, Yuxuan Shui wrote:




 naming args is not mandatory.
 using names depends from user of lib not from lib itself or 
 compiler.


but when overload rules points to method that haven't any of 
named args that user choose - ERROR, user should understand that 
method that user probably want to invoke (expect) is not method 
that compiler will invoke - and this is ERROR that user should 
fix.
Sep 12 2019
prev sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Thursday, 12 September 2019 at 12:19:51 UTC, a11e99z wrote:

 On Thursday, 12 September 2019 at 12:15:57 UTC, a11e99z wrote:

 On Thursday, 12 September 2019 at 11:46:46 UTC, rikki 
 cattermole wrote:

 On 12/09/2019 11:29 PM, Yuxuan Shui wrote:




 naming args is not mandatory.
 using names depends from user of lib not from lib itself or 
 compiler.


In DIP 1020, naming arguments is mandatory.
Sep 12 2019
parent reply a11e99z <black80 bk.ru> writes:
On Thursday, 12 September 2019 at 13:44:52 UTC, Paul Backus wrote:

 On Thursday, 12 September 2019 at 12:19:51 UTC, a11e99z wrote:

 On Thursday, 12 September 2019 at 12:15:57 UTC, a11e99z wrote:

 On Thursday, 12 September 2019 at 11:46:46 UTC, rikki 
 cattermole wrote:

 On 12/09/2019 11:29 PM, Yuxuan Shui wrote:




 naming args is not mandatory.
 using names depends from user of lib not from lib itself or 
 compiler.


 In DIP 1020, naming arguments is mandatory.


this is not good.

it was not good cuz method can be called with mixing named and 
positional args

 func( 1, z: 3, y: 2, 4 ); // and comma is float-dot for some 
 human langs


and optional can be mixed(before) with required args

 void func( int one, float two =2, string three ) { }


and now is not good from other side:
u can not call method without naming args when  named exists in 
definition.

"out of the frying pan into the fire"

I dont like such named args.

---------------------

- defaulted/optional args only in the end of args list (function 
definition).
- naming args is not mandatory (function call).
- named args only after positional/required args not intermixing 
(func call).
- order for named args doesn't matter (func call).
- required/positional/non-defaulted args should be assigned (func 
call).
- and assigning arg more than once is error.


 void func( int one, float two =5, string three ); // ERROR. 
 optional before required.
 void func( int one, float two, string three, int four = 123, 
 float five = 3.14 );



 func( 1, 2, "3", 4, 5 ); // OK
 func( 1, five: 2.72, 2, four: 321, three: "hello" ); // ERROR. 
 named before positional
 func( 1, five: 3e8, four: 4, three: "3", two: 2 ); // OK
 func( 1, 2, four: 321 ); // ERROR. required "three" is not 
 assigned
 func( 1, three: "hello", two: 2 ); // OK
 func( 1, 2, three: "hello", two: 2 ); // ERROR. "two" assigned 
 twice


---------------------

what the reason do mandatory naming for  named args?
arg names will also be involved in choosing the right method 
along with overloading and templates and UFCS?
Sep 12 2019
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 13/09/2019 2:37 AM, a11e99z wrote:

 arg names will also be involved in choosing the right method along with 
 overloading and templates and UFCS?


No they will not be.

If they were, it would effect function and symbol overloading which 
would require mangling changes. It is a very invasive set of changes 
that would cause problems in implementation. It is not something that 
should be considered unless you are a compiler developer with an 
implementation that is tested.
Sep 12 2019
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
I'm going to be blunt, so shields up!

For DIP 1020 and DIP 1019, I keep trying to nudge things in the direction of a 
better design:

https://digitalmars.com/d/archives/digitalmars/D/DIP_1020--Named_Parameters--Community_Review_Round_1_325299.html#N325627

All to no avail. It pains me a great deal to see all this effort and discussion 
going down the drain on designs that are both more complex and inadequate. The 
authors have exhibited little or no interest in either adopting my suggestions 
or explaining why theirs are better.

Andrei and Atila have tried as well.

This has gone on long enough. DIP 1019 and 1020 are not going to be approved.

(It is clear that a lot of time was spend on the DIPs, and they are well
written 
and presented. The authors should be proud of them. It's just that we have a 
better design.)
Sep 13 2019
next sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Friday, 13 September 2019 at 07:56:38 UTC, Walter Bright wrote:

 I'm going to be blunt, so shields up!

 For DIP 1020 and DIP 1019, I keep trying to nudge things in the 
 direction of a better design:

 https://digitalmars.com/d/archives/digitalmars/D/DIP_1020--Named_Parameters--Community_Review_Round_1_325299.html#N325627

 All to no avail. It pains me a great deal to see all this 
 effort and discussion going down the drain on designs that are 
 both more complex and inadequate. The authors have exhibited 
 little or no interest in either adopting my suggestions or 
 explaining why theirs are better.

 Andrei and Atila have tried as well.

 This has gone on long enough. DIP 1019 and 1020 are not going 
 to be approved.

 (It is clear that a lot of time was spend on the DIPs, and they 
 are well written and presented. The authors should be proud of 
 them. It's just that we have a better design.)


Thank you for saying this Walter.  This is going to save so many 
people so much time.
Sep 13 2019
parent reply M.M. <matus email.cz> writes:
On Friday, 13 September 2019 at 16:02:48 UTC, Jonathan Marler 
wrote:

 On Friday, 13 September 2019 at 07:56:38 UTC, Walter Bright 
 wrote:

 [...]


 Thank you for saying this Walter.  This is going to save so 
 many people so much time.


But it was a really good and constructive discussion around! Well 
done to the authors of the two DIPs. I wish they could find the 
energy to come up with a new DIP...
Sep 13 2019
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 14/09/2019 5:49 AM, M.M. wrote:

 I wish they could find the energy to come up with a new DIP..


No point on my end.

I may as well explain why I created DIP 1020 officially now that it is dead.

The reason is signatures.



Signatures is a language feature that originates from the ML family of 
languages.

It is in my opinion the best companion to meta-programming and CTFE you 
could ever have.

 From a runtime perspective it would be a vtable, with method bodies 
being able to be patched on top of the implementation type (struct or 
class) so that the interface (signature) could adapt to the 
implementation silently.

At compile time it would act as a type verifier like isInputRange and 
friends.

It could infer its template instance type from an implementation with 
automatic binding named parameters to types and constants of the 
implementation. Separating the interface elements like the ElementType 
of an input range from the implementation and allowing some information 
transfer so it could be passed around at runtime.

The design elements from DIP 1020 that would have allowed for this are 
not wanted by the community or by Walter.

There is nothing I can do without butchering this concept to make it as 
powerful as it could have been.



"It is possible to commit no mistakes and still lose. That is not a 
weakness. That is life." - Jean-Luc Picard
Sep 13 2019
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Friday, 13 September 2019 at 18:29:56 UTC, rikki cattermole 
wrote:

 On 14/09/2019 5:49 AM, M.M. wrote:

 I wish they could find the energy to come up with a new DIP..


 No point on my end.

 I may as well explain why I created DIP 1020 officially now 
 that it is dead.

 The reason is signatures.
 [snip]


I feel like this is an argument you should have made much 
earlier...like...in the DIP...

You are getting frustrated because others are not seeing your 
vision (butchering the DIP). However, we are not privy to what 
you have in the back of your mind (type signatures) without those 
thoughts being clearly spelled out. People were evaluating DIP 
1020 on its merits and Walter's suggestions on its merits. DIP 
1020 doesn't mention type signatures and why your version of 
named parameters enables that pattern. Walter's idea may or may 
not enable your vision of type signatures (I have no idea without 
more details...and even then may have no idea), but that was 
never mentioned as a justification for the DIP.

As an aside, you may also find some of the discussion from the 
DIP 1023 review thread interesting [1]. Later in the thread, I 
describe the possibility of using alias templates as types and 
incorporating Atila's concepts library to provide improved error 
messages. Of course, there is no run-time component here.

[1] 
https://forum.dlang.org/thread/dnyqxmgdazczwmmvayjx forum.dlang.org
Sep 13 2019
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 14/09/2019 7:48 AM, jmh530 wrote:

 On Friday, 13 September 2019 at 18:29:56 UTC, rikki cattermole wrote:

 On 14/09/2019 5:49 AM, M.M. wrote:

 I wish they could find the energy to come up with a new DIP..


 No point on my end.

 I may as well explain why I created DIP 1020 officially now that it is 
 dead.

 The reason is signatures.
 [snip]


 
 I feel like this is an argument you should have made much 
 earlier...like...in the DIP...


I felt it was inappropriate to state such possibilities in the DIP or in 
the review thread(s) as it may never came to pass.

As per the spirit of the DIP process, a DIP by itself should function as 
a whole and not rely on future potential DIP's for its merit. Examples 
of this can be seen in DIP 1019's review threads.

I consider DIP 1020 to have done that. Served its use cases that were 
numerous without needing a potential DIP to the future to describe its 
potential. However I doubt many people would agree with my belief in that.

Anyway the concept of signatures that I have, while spending 2 years on 
it up to now, I had concluded before DIP 1020 was created that the only 
way to implement it was to break it up into much smaller design problems 
and named arguments happened to fit a key part of it.

It would have been equivalent of adding a class system to D. That is not 
a small design problem and could of easily damaged the language if done 
wrong.

Perhaps it would have been possible 10 years ago, but D is a production 
language. It had a high chance of failure.
Sep 13 2019
prev sibling parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
On Friday, 13 September 2019 at 07:56:38 UTC, Walter Bright wrote:

 I'm going to be blunt, so shields up!

 For DIP 1020 and DIP 1019, I keep trying to nudge things in the 
 direction of a better design:

 https://digitalmars.com/d/archives/digitalmars/D/DIP_1020--Named_Parameters--Community_Review_Round_1_325299.html#N325627

 All to no avail. It pains me a great deal to see all this 
 effort and discussion going down the drain on designs that are 
 both more complex and inadequate. The authors have exhibited 
 little or no interest in either adopting my suggestions or 
 explaining why theirs are better.

 Andrei and Atila have tried as well.

 This has gone on long enough. DIP 1019 and 1020 are not going 
 to be approved.

 (It is clear that a lot of time was spend on the DIPs, and they 
 are well written and presented. The authors should be proud of 
 them. It's just that we have a better design.)


That is fair. But keep in mind there is a difference here. DIP 
1019/1020 are _ready_, meaning they can start to be implemented 
once approved. OTOH, the better design is still just an idea, and 
no one seems to be willing to take on the task to write a DIP for 
it.

Is it a good idea to stall a useful feature indefinitely because 
there is some potential better design?

(Yes, I'm bitter and biased, but I still this is a legitimate 
question to ask.).
Sep 15 2019
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 16/09/2019 2:32 AM, Yuxuan Shui wrote:

 On Friday, 13 September 2019 at 07:56:38 UTC, Walter Bright wrote:

 I'm going to be blunt, so shields up!

 For DIP 1020 and DIP 1019, I keep trying to nudge things in the 
 direction of a better design:

 https://digitalmars.com/d/archives/digitalmars/D/DIP_1020--Named_Parameters--Community_Review_Round_1
325299.html#N325627 


 All to no avail. It pains me a great deal to see all this effort and 
 discussion going down the drain on designs that are both more complex 
 and inadequate. The authors have exhibited little or no interest in 
 either adopting my suggestions or explaining why theirs are better.

 Andrei and Atila have tried as well.

 This has gone on long enough. DIP 1019 and 1020 are not going to be 
 approved.

 (It is clear that a lot of time was spend on the DIPs, and they are 
 well written and presented. The authors should be proud of them. It's 
 just that we have a better design.)


 
 That is fair. But keep in mind there is a difference here. DIP 1019/1020 
 are _ready_, meaning they can start to be implemented once approved. 
 OTOH, the better design is still just an idea, and no one seems to be 
 willing to take on the task to write a DIP for it.
 
 Is it a good idea to stall a useful feature indefinitely because there 
 is some potential better design?
 
 (Yes, I'm bitter and biased, but I still this is a legitimate question 
 to ask.).


Walter has begun working on it as stated on his Twitter account[0].

I have given him feedback to help improve it via Twitter. It has a long 
way to go given the feedback the DIPs 1019+1020 received (which IMHO has 
set a precedent for what it needs to include).

[0] https://twitter.com/WalterBright/status/1173165009926443009
Sep 15 2019
next sibling parent Yuxuan Shui <yshuiv7 gmail.com> writes:
On Sunday, 15 September 2019 at 14:50:06 UTC, rikki cattermole 
wrote:

 On 16/09/2019 2:32 AM, Yuxuan Shui wrote:

 [...]


 Walter has begun working on it as stated on his Twitter 
 account[0].

 I have given him feedback to help improve it via Twitter. It 
 has a long way to go given the feedback the DIPs 1019+1020 
 received (which IMHO has set a precedent for what it needs to 
 include).

 [0] https://twitter.com/WalterBright/status/1173165009926443009


I'm always one step behind, aren't I.

That is great news.
Sep 15 2019
prev sibling next sibling parent reply M.M. <matus email.cz> writes:
On Sunday, 15 September 2019 at 14:50:06 UTC, rikki cattermole 
wrote:

 On 16/09/2019 2:32 AM, Yuxuan Shui wrote:

 [...]


 Walter has begun working on it as stated on his Twitter 
 account[0].

 I have given him feedback to help improve it via Twitter. It 
 has a long way to go given the feedback the DIPs 1019+1020 
 received (which IMHO has set a precedent for what it needs to 
 include).

 [0] https://twitter.com/WalterBright/status/1173165009926443009


Is Walter's approach compatible with your idea of to signatures?
Sep 15 2019
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 16/09/2019 6:34 AM, M.M. wrote:

 On Sunday, 15 September 2019 at 14:50:06 UTC, rikki cattermole wrote:

 On 16/09/2019 2:32 AM, Yuxuan Shui wrote:

 [...]


 Walter has begun working on it as stated on his Twitter account[0].

 I have given him feedback to help improve it via Twitter. It has a 
 long way to go given the feedback the DIPs 1019+1020 received (which 
 IMHO has set a precedent for what it needs to include).

 [0] https://twitter.com/WalterBright/status/1173165009926443009


 
 Is Walter's approach compatible with your idea of to signatures?


Its compatible just like how a bool is an integer is compatible to 
signatures.

Basically there needs to be a way to represent properties (as in 
members) on the type (types/constants) that can then be set by the user 
(for i.e. heap storage) and inferred by the implementation type i.e.

static assert(InputRange(Map(...)).ElementType == Map.ElementType);
static assert(InputRange(Map(...)) == InputRange(Filter(...)));

struct Map {
	alias ElementType = int;
}

struct Filter {
	alias ElementType = int;
}

signature InputRange( named ElementType) {
	...
}

The above ignores things like memory management but it does give a basic 
overview of why Walter's design doesn't do anything for my design of 
signatures.
Sep 16 2019
parent reply M.M. <matus email.cz> writes:
On Monday, 16 September 2019 at 11:32:35 UTC, rikki cattermole 
wrote:

 [...]

 The above ignores things like memory management but it does 
 give a basic overview of why Walter's design doesn't do 
 anything for my design of signatures.


But if I understand it correctly, Walter's design also does not 
stand in bringing a design of signatures?
Sep 17 2019
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 17/09/2019 8:38 PM, M.M. wrote:

 On Monday, 16 September 2019 at 11:32:35 UTC, rikki cattermole wrote:

 [...]

 The above ignores things like memory management but it does give a 
 basic overview of why Walter's design doesn't do anything for my 
 design of signatures.


 
 But if I understand it correctly, Walter's design also does not stand in 
 bringing a design of signatures?


It does not no.

My current design which I created as a backup to DIP1020 which supports 
his, I do not believe fits in with the current design of signatures.

I.e.

struct Foo(public T) {
}

static asssert(Foo!(T: int).T == int);
Sep 17 2019
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 17 September 2019 at 12:37:50 UTC, rikki cattermole 
wrote:

 [snip]

 It does not no.

 My current design which I created as a backup to DIP1020 which 
 supports his, I do not believe fits in with the current design 
 of signatures.

 I.e.

 struct Foo(public T) {
 }

 static asssert(Foo!(T: int).T == int);


I think I'm starting to understand your signatures idea from this.

That being said, I think this would be a lot simpler if types 
were first class citizens. If they were, then you could easily 
return types from functions. So instead of your Foo above, you 
could have

struct Foo(T) {
     type T() {
         return T;
     }
}

You could write mixins to automatically generate those functions 
pretty easily as a first step.

Above you have an example with


 signature InputRange( named ElementType) {
 	...
 }


But I think this would have the same issue as your  named syntax.
Sep 17 2019
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 18/09/2019 1:13 AM, jmh530 wrote:

 On Tuesday, 17 September 2019 at 12:37:50 UTC, rikki cattermole wrote:

 [snip]

 It does not no.

 My current design which I created as a backup to DIP1020 which 
 supports his, I do not believe fits in with the current design of 
 signatures.

 I.e.

 struct Foo(public T) {
 }

 static asssert(Foo!(T: int).T == int);


 
 I think I'm starting to understand your signatures idea from this.
 
 That being said, I think this would be a lot simpler if types were first 
 class citizens. If they were, then you could easily return types from 
 functions. So instead of your Foo above, you could have
 
 struct Foo(T) {
      type T() {
          return T;
      }
 }
 
 You could write mixins to automatically generate those functions pretty 
 easily as a first step.


So with signatures you essentially need a separate parameter type which 
says: will probably be inferred from something but can be set by the 
user if they really need to.

In your above example, I suspect it will have name collisions as-is.

Sadly I don't see a way to make these parameters actually part of the 
body of a signature where they belong. They are a property of a 
signature just like sizeof is, no difference between them. But they are 
template parameters too. Not great for syntax when ``alias T;`` is 
already legal.


 Above you have an example with
 

 signature InputRange( named ElementType) {
     ...
 }


 
 But I think this would have the same issue as your  named syntax.


That is an example using known semantics + syntax, it is DIP 1020 ;)
Sep 17 2019
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 17 September 2019 at 13:36:59 UTC, rikki cattermole 
wrote:

 [snip]

 So with signatures you essentially need a separate parameter 
 type which says: will probably be inferred from something but 
 can be set by the user if they really need to.

 In your above example, I suspect it will have name collisions 
 as-is.

 [snip]


Would it help to use opDispatch? Maybe something like below 
(assuming types are first class objects):

struct Foo(T) {
     type opDispatch(string U)()
         if (is(T == mixin(U))
     {
         return mixin(U);
     }
}
Sep 17 2019
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 18/09/2019 1:52 AM, jmh530 wrote:

 On Tuesday, 17 September 2019 at 13:36:59 UTC, rikki cattermole wrote:

 [snip]

 So with signatures you essentially need a separate parameter type 
 which says: will probably be inferred from something but can be set by 
 the user if they really need to.

 In your above example, I suspect it will have name collisions as-is.

 [snip]


 
 Would it help to use opDispatch? Maybe something like below (assuming 
 types are first class objects):
 
 struct Foo(T) {
      type opDispatch(string U)()
          if (is(T == mixin(U))
      {
          return mixin(U);
      }
 }


Yes.

But as a language feature I have no idea what first class types would do 
in D.

For example:

alias Foo(T) = T.U;

in long form:

template Foo(T) {
	alias Foo = T.U;
}

So we already have "functions" that return types+constants already.
Sep 17 2019
parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 17 September 2019 at 13:58:06 UTC, rikki cattermole 
wrote:

 [snip]

 But as a language feature I have no idea what first class types 
 would do in D.

 For example:

 alias Foo(T) = T.U;

 in long form:

 template Foo(T) {
 	alias Foo = T.U;
 }

 So we already have "functions" that return types+constants 
 already.


I don't know if I would call that a function...but I see your 
point.

T.U doesn't work currently in this case of course.
Sep 17 2019
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/15/2019 7:50 AM, rikki cattermole wrote:

 Walter has begun working on it as stated on his Twitter account[0].
 
 I have given him feedback to help improve it via Twitter. It has a long way to 
 go given the feedback the DIPs 1019+1020 received (which IMHO has set a 
 precedent for what it needs to include).
 
 [0] https://twitter.com/WalterBright/status/1173165009926443009


Thanks for the feedback!

(Technical feedback should go on the github page, not twitter.)
Sep 15 2019
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
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"


You're forbidding calling a function with a positional argument 
coming after a named argument, except when the order is exactly 
the same as in the function definition. I don't think that's a 
good idea, because it makes order of the named parameters 
relevant. That may make the function complex to ABI mangle, and 
prevents function definer from freely reordering named parameters 
afterwards. I think you should either:

-require named arguments to come last in the call (and perhaps 
the corresponding parameters in the function definition)
-allow a positional argument to come last in any case. The caller 
may stick named arguments anywhere in the argument list, only 
exception being that named parameter can't be passed by UFCS.

Otherwise I like this. The best named argument proposal in the 
reviews so far.
Sep 24 2019
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 25/09/2019 3:49 AM, Dukc wrote:

 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"


 
 You're forbidding calling a function with a positional argument coming 
 after a named argument, except when the order is exactly the same as in 
 the function definition. I don't think that's a good idea, because it 
 makes order of the named parameters relevant. That may make the function 
 complex to ABI mangle, and prevents function definer from freely 
 reordering named parameters afterwards. I think you should either:


That's not true.
The order is relative to the other named parameters except when no 
positional arguments follow.

This DIP does not change ABI mangling since named parameters do not get 
mangled (they also don't get considered for overload resolution so that 
makes it possible).


 -require named arguments to come last in the call (and perhaps the 
 corresponding parameters in the function definition)
 -allow a positional argument to come last in any case. The caller may 
 stick named arguments anywhere in the argument list, only exception 
 being that named parameter can't be passed by UFCS.
 
 Otherwise I like this. The best named argument proposal in the reviews 
 so far.


Thanks, however Walter has killed this DIP so that's that I'm afraid.
Sep 24 2019
parent reply Dukc <ajieskola gmail.com> writes:
On Tuesday, 24 September 2019 at 17:15:51 UTC, rikki cattermole 
wrote:

 That's not true.
 The order is relative to the other named parameters except when 
 no positional arguments follow.


Hmm, sounds somewhat better. Well, the implementor can define the 
parameters last if he wants to be free to reorder afterwards.


 This DIP does not change ABI mangling since named parameters do 
 not get mangled (they also don't get considered for overload 
 resolution so that makes it possible).


They do not have to be mangled, but the implementor might want to 
generate a hash from named parameters to the mangling, to avoid 
linking to a function that has different named parameters.


 Thanks, however Walter has killed this DIP so that's that I'm 
 afraid.


My symphaties. Ask Mike to mark the DIP postponed? Walter's DIP 
has not yet passed the reviews, so there's always the possibility 
that someone uncovers a major flaw. In that case, it's good to 
have a backup DIP.
Sep 24 2019
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 25/09/2019 7:57 AM, Dukc wrote:

 On Tuesday, 24 September 2019 at 17:15:51 UTC, rikki cattermole wrote:

 That's not true.
 The order is relative to the other named parameters except when no 
 positional arguments follow.


 
 Hmm, sounds somewhat better. Well, the implementor can define the 
 parameters last if he wants to be free to reorder afterwards.


We are mixing terminology I fear.

Parameter = declaration side
Argument = caller side

Parameters can be in any order.
Named arguments must remain in order of the named parameter list until 
the last unnamed argument. After that its any order.


 This DIP does not change ABI mangling since named parameters do not 
 get mangled (they also don't get considered for overload resolution so 
 that makes it possible).


 
 They do not have to be mangled, but the implementor might want to 
 generate a hash from named parameters to the mangling, to avoid linking 
 to a function that has different named parameters.


I've considered this, there is no benefit. Mangling is not a safety 
feature. It only exists to make symbol overloading possible.


 Thanks, however Walter has killed this DIP so that's that I'm afraid.


 
 My symphaties. Ask Mike to mark the DIP postponed? Walter's DIP has not 
 yet passed the reviews, so there's always the possibility that someone 
 uncovers a major flaw. In that case, it's good to have a backup DIP.


There shouldn't be any major issues with his.
Apart from one or two invasive changes which he is more than capable of 
implementing himself (and maybe the only one I would trust doing it) its 
pretty light on features.
Sep 24 2019
parent Dukc <ajieskola gmail.com> writes:
On Tuesday, 24 September 2019 at 20:05:04 UTC, rikki cattermole 
wrote:

 Ask Mike to mark the DIP postponed? Walter's DIP has not yet 
 passed the reviews, so there's always the possibility that 
 someone uncovers a major flaw. In that case, it's good to have 
 a backup DIP.


 There shouldn't be any major issues with his.
 Apart from one or two invasive changes which he is more than 
 capable of implementing himself (and maybe the only one I would 
 trust doing it) its pretty light on features.


Regardless. A DIP may be fundamentally flawed even if it's 
implementable and does not break anything. It may close the door 
off from some important future change, or have some side-effect 
that's hard to see in advance. That's the very reason for this 
whole review process.
Sep 25 2019