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
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
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)
As a C# programmer which has this feature too, this is excessively noise in contrast. Wouldn't be easier to go with Opt-Out (Or In) with a flag on Compiler level? S.
Sep 10
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)
As a C# programmer which has this feature too, this is excessively noise 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
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
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
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 still overblown, I never encounter anyone in the C# who complains 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
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 
 overblown, I never encounter anyone in the C# who complains about code 
 breakage regarding named arguments.
The design C# has taken, was more restrictive and quite importantly more conservative than both mine and Walter's. That may have been a key factor in it not breaking peoples code. 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
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 
 still overblown, I never encounter anyone in the C# who 
 complains about code breakage regarding named arguments.
The design C# has taken, was more restrictive and quite importantly more conservative than both mine and Walter's. That may have been a key factor in it not breaking peoples code.
Having read DIP 1020, Walter's proposal, and the C# article, the only difference I can find (leaving aside the parts about templates) is that C# is more restrictive about how named arguments may be reordered. I fail to see how this difference could possibly have any impact on the potential for code breakage, since if a parameter name is changed, code will break regardless of what order the arguments are passed in. If there's some other difference I'm missing that puts DIP 1020 and Walter's proposal at greater risk of breaking code than C#'s named arguments, I'd appreciate if you could point it out explicitly, since I am probably not the only one to have overlooked it.
Sep 10
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 
 overblown, I never encounter anyone in the C# who complains about 
 code breakage regarding named arguments.
The design C# has taken, was more restrictive and quite importantly more conservative than both mine and Walter's. That may have been a key factor in it not breaking peoples code.
Having read DIP 1020, Walter's proposal, and the C# article, the only difference I can find (leaving aside the parts about templates) is that C# is more restrictive about how named arguments may be reordered. I fail to see how this difference could possibly have any impact on the potential for code breakage, since if a parameter name is changed, code will break regardless of what order the arguments are passed in. If there's some other difference I'm missing that puts DIP 1020 and Walter's proposal at greater risk of breaking code than C#'s named arguments, I'd appreciate if you could point it out explicitly, since I am probably not the only one to have overlooked it.
"No breaking changes are expected except in the case that any codebase declares an existing UDA called named." I do not expect code breakage to occur in either case. But I am concerned about the possibility and would prefer to design a little defensively (a few things like is expression handling for templates could break code if it was designed in a different way in DIP 1020).
Sep 10
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 
 is still overblown, I never encounter anyone in the C# who 
 complains about code breakage regarding named arguments.
The design C# has taken, was more restrictive and quite importantly more conservative than both mine and Walter's. That may have been a key factor in it not breaking peoples code.
Having read DIP 1020, Walter's proposal, and the C# article, the only difference I can find (leaving aside the parts about templates) is that C# is more restrictive about how named arguments may be reordered. I fail to see how this difference could possibly have any impact on the potential for code breakage, since if a parameter name is changed, code will break regardless of what order the arguments are passed in. If there's some other difference I'm missing that puts DIP 1020 and Walter's proposal at greater risk of breaking code than C#'s named arguments, I'd appreciate if you could point it out explicitly, since I am probably not the only one to have overlooked it.
"No breaking changes are expected except in the case that any codebase declares an existing UDA called named." I do not expect code breakage to occur in either case. But I am concerned about the possibility and would prefer to design a little defensively (a few things like is expression handling for templates could break code if it was designed in a different way in DIP 1020).
I think you've misunderstood what 12345swordy and I are saying. The concern is not that DIP 1020 (or any other implementation of named arguments) will cause breakage *itself*, but that making parameter names part of a function's public interface could lead indirectly to *future* code breakage if any of those names are changed. 12345swordy's point #3 was that the above concern is, in his opinion, overblown, and that therefore we shouldn't bother requiring a named attribute on parameters to address it. Personally, I share this opinion; my own experience in Python (which handles named arguments similarly to C#) is that parameter-name changes are not a problem in practice.
Sep 10
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.
 
 12345swordy's point #3 was that the above concern is, in his opinion, 
 overblown, and that therefore we shouldn't bother requiring a  named 
 attribute on parameters to address it. Personally, I share this opinion; 
 my own experience in Python (which handles named arguments similarly to 
 C#) is that parameter-name changes are not a problem in practice.
Oh okay in that case, I do agree with both of you that potential breakage for name changes is over blown. However DIP 1020 is opt-in and that design decision permeates throughout the entire DIP. Unlike syntax, I cannot change this without recreating the DIP from scratch. To me named arguments work best when the API author is the one who made the decision to make it named. Not the API user. Ada and Python are both good examples of opt-in named arguments made by the API author. Ultimately D is a production language. Adding a language feature like named arguments so late could end badly if it intends to add new patterns of code that do not have solid examples in many existing code bases.
Sep 10
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
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
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
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
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
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
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
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
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
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
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
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 language alongside ones with significant adoption like C# and Swift? Is it just to give an example of C#'s syntax with a different reordering rule? If so, isn't the fact that you couldn't find a mainstream example of this reordering rule evidence against considering it?
 Python

 [...]
 Parameter syntax: ** Identifier
This is inaccurate, or at least incomplete. All function parameters in Python can be passed by name; no special parameter syntax is required to enable named arguments. The syntax `** Identifier` (usually written `**kwargs`) is used specifically for *variadic* keyword arguments.
 Parameters must be marked as accepting named arguments, 
 otherwise there will
 be no way to determine which overload to resolve.
The DIP needs to explain why this is true, not just assert it. At the very least, it should give an example of a function call for which overload resolution would fail if named parameters were not explicitly marked.
 It is the author's opinion that the is expression is heavily 
 overloaded and
 doing too much. It should be possible to access the names of 
 named template
 parameters outside of an instantiated template, but it should 
 be done with a
 mechanism other than the is expression.
Personal opinion is an extremely weak justification, and unlikely to convince anyone who does not already agree with the DIP's author. This section would be much more convincing if it compared and contrasted both approaches, and listed the pros and cons of each.
 The  named attribute prevents clashes with other existing 
 language features
 like template specializations (e.g., T:V or T=int). It aims to 
 be opt-in
 rather than opt-out to prevent clashes with core semantics of 
 the D
 programming language like function overloading.
The DIP should give specific examples of these "clashes" and explain how named prevents them, rather than speaking in vague, general terms.
 The order of evaluation of named function arguments follows the 
 lexical order
 of the argument list (full, not subset).
What does "(full, not subset)" mean? This is the only usage of the word "subset" in the entire DIP. The DIP should define any new terms it intends to use, rather than assume that the reader will infer the correct meaning from context.
 Two new traits are added to support type inspection. The first 
 addition is
 the isNamedParameter trait, which allows a given parameter from 
 the parameter
 list of a function, delegate, or a function pointer to be 
 inspected for the
 presence of the  named attribute. This is intended to be used 
 with the
 __parameters specialization of the is expression. The second 
 addition is the
 getNamedParameters trait, which returns a list of all named 
 parameters from
 the parameter list of a given template, function, delegate, or 
 function
 pointer.
Why not have isNamedParameter work for templates too, and get rid of getNamedParameters?
 Overload resolution for symbols (for function and template 
 declarations) is
 performed without taking named parameters into account. 
 Ignoring named
 parameters in both cases means that the relevant algorithms and 
 user code
 does not need to change to accommodate named parameters but 
 they must be
 modified to filter them out. This is in line with the current 
 behavior. A
 side effect of this is that name mangling does not need to 
 change to
 accommodate these new parameters.

 [...]

     void foo(int a) {
     }

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

 [...]

     foo(1); // error: matches both declarations
     foo(1, b: 2); // error: matches both declarations
Given that the function calls are unambiguous as written, it seems very strange for the compiler to reject them. The DIP should explain, preferably with examples, what problems would be caused by allowing the compiler to accept these calls--i.e., what "algorithms and user code" would need to be changed, and how burdensome those changes would be.
 Template declarations that have named parameters expose the 
 named parameter as a member of the template.
This feature is not essential to the DIP, so its inclusion needs to be justified separately.
 Manifest constant templates and templated aliases are treated 
 as if they were
 eponymous templates and do expose named parameters as members.
Non-eponymous members of eponymous templates are currently inaccessible from outside the template body, so this will require changes to D's name lookup rules. Example: template size(T_) { alias T = T_; enum size = T_.sizeof; } // Error: no property T for type ulong pragma(msg, size!int.T);
 * named arguments at the end of an argument list may appear in 
 any order

 * named arguments may be interleaved with positional arguments 
 out of
 sequence, but if there are more than one they must match the 
 order in which
 the named parameters are declared
The DIP should explain why these particular reordering rules were chosen instead of any of the alternatives from previous proposals, or from the examples given in the "Prior Work" section.
Sep 10
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 language alongside ones with significant adoption like C# and Swift? Is it just to give an example of C#'s syntax with a different reordering rule? If so, isn't the fact that you couldn't find a mainstream example of this reordering rule evidence against considering it?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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. --------------------- I like C# naming more and more: - 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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