www.digitalmars.com         C & C++   DMDScript  

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

reply Mike Parker <aldacron gmail.com> writes:
This is the feedback thread for the first round of Community Review for 
DIP 1020, "Named Parameters":

https://github.com/dlang/DIPs/blob/39dbbbe5e4618abd4c4b41eb0edd16547858ddf5/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 April 14, or 
when I make a post declaring it complete.

At the end of Round 1, 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 by the 
language maintainers.

Please familiarize yourself with the documentation for the Community 
Review before participating.

https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#community-review

Thanks in advance to all who participate.
Mar 31
next sibling parent reply kinke <noone nowhere.com> writes:
 void func(int a, int b, <bool o>);
I find the syntax terrible. IMO, any extra syntax in the signature isn't acceptable; it should be call-sites-specific only, i.e., C#-style.
Mar 31
parent reply Kagamin <spam here.lot> writes:
On Sunday, 31 March 2019 at 13:11:48 UTC, kinke wrote:
 void func(int a, int b, <bool o>);
I find the syntax terrible. IMO, any extra syntax in the signature isn't acceptable; it should be call-sites-specific only, i.e., C#-style.
AFAIK, languages don't have dedicated named parameters.
Apr 01
parent Paul Backus <snarwin gmail.com> writes:
On 4/1/19 6:14 AM, Kagamin wrote:
 On Sunday, 31 March 2019 at 13:11:48 UTC, kinke wrote:
 void func(int a, int b, <bool o>);
I find the syntax terrible. IMO, any extra syntax in the signature isn't acceptable; it should be call-sites-specific only, i.e., C#-style.
AFAIK, languages don't have dedicated named parameters.
Scheme [1] and Common Lisp [2] both have dedicated named parameters. It's uncommon, but not completely unheard-of. [1] https://srfi.schemers.org/srfi-89/srfi-89.html [2] http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/sec_3-4-1-4.html
Apr 01
prev sibling next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Sunday, 31 March 2019 at 12:33:56 UTC, Mike Parker wrote:
 This is the feedback thread for the first round of Community 
 Review for DIP 1020, "Named Parameters":

 https://github.com/dlang/DIPs/blob/39dbbbe5e4618abd4c4b41eb0edd16547858ddf5/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 April 14, or when I make a post declaring it complete.

 At the end of Round 1, 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 by the language maintainers.

 Please familiarize yourself with the documentation for the 
 Community Review before participating.

 https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#community-review

 Thanks in advance to all who participate.
I don't like the angle brackets for the aesthetic reason that it loos like C++ and for the practical reason that there is an asymmetry w.r.t. the way it is declared and the way it is used. I would much prefer void func(int a, int b, bool:o); ... func(1, 2, o:true); Section "Use Cases" needs more explanation: I don't see how the ranges example revokes the need for ElementType, perhaps a "before and after" would be useful here.
Mar 31
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
On 3/31/2019 9:33 PM, Mike Parker wrote:
 This is the feedback thread for the first round of Community Review for 
 DIP 1020, "Named Parameters":
 
 https://github.com/dlang/DIPs/blob/39dbbbe5e4618abd4c4b41eb0edd16547858
df5/DIPs/DIP1020.md 
 
The following link has a couple of source code formatting errors fixed: https://github.com/dlang/DIPs/blob/367741ed43d2491f25542b6fda043ad1d81a1461/DIPs/DIP1020.md And of course, the latest version is always available at: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1020.md
Mar 31
prev sibling next sibling parent Paul Backus <snarwin gmail.com> writes:
On 3/31/19 8:33 AM, Mike Parker wrote:
 This is the feedback thread for the first round of Community Review for
 DIP 1020, "Named Parameters":
Some remarks: 1. The angle-bracket syntax is an odd choice. There's no precedent in D (or, as far as I know, any other language) for angle-brackets indicating that names are significant, so anyone encountering this syntax for the first time is going to have to look it up to know what it means. If they're clever, and speak English well enough to know that "<>" are called "angle brackets", they'll still have to avoid getting sidetracked by the "Template Comparison" [1] page in order to find the page in the language spec that covers named parameters (which hopefully includes the words "angle brackets" itself...). Ironically, I think this version of named parameters would be a much better fit for an attribute like named or keyword than the one in DIP 1019. Not only would such an attribute convey its meaning better to an unfamiliar reader than angle brackets, it would also be much easier to search for. 2. The feature that allows named parameters of templates to be accessed as though they were members of the template requires explicit justification for its inclusion. It is (a) orthogonal to the rest of the proposal, (b) possible to implement in user code, either by hand or as a mixin template, and (c) an unavoidable source of namespace pollution. The interaction with eponymous templates is also non-obvious. Naively, one might expect the eponymous member and the named-argument members to be siblings, but in the case of (e.g.) `struct Foo<T> {}`, the member for T is actually *inside* the eponymous member. I'm sure there are good reasons for proposing this feature, but those reasons need to be stated directly in the DIP itself, not left for the reader to infer. 3. The "Future Proposals" section is very weak. Adding ordering restrictions after the fact would be a breaking change, and the hypothetical "API Alias Parameters" feature is difficult to understand and of no obvious use without further elaboration. I would recommend removing this section from the DIP entirely. [1] https://dlang.org/articles/template-comparison.html
Mar 31
prev sibling next sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Sunday, 31 March 2019 at 12:33:56 UTC, Mike Parker wrote:
 This is the feedback thread for the first round of Community 
 Review for DIP 1020, "Named Parameters":

 https://github.com/dlang/DIPs/blob/39dbbbe5e4618abd4c4b41eb0edd16547858ddf5/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 April 14, or when I make a post declaring it complete.

 At the end of Round 1, 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 by the language maintainers.

 Please familiarize yourself with the documentation for the 
 Community Review before participating.

 https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#community-review

 Thanks in advance to all who participate.
I still have the opinion we should go for in place struct initialization first. Here we get named parameters implicit without adding a complete new syntax. I also do not like the new syntax <>. Leveraging what inplace struct initialization syntax gives us, seems a lot more reasonable in my opinion. Kind regards Andre
Mar 31
next sibling parent Kagamin <spam here.lot> writes:
On Sunday, 31 March 2019 at 15:53:53 UTC, Andre Pany wrote:
 I still have the opinion we should go for in place struct 
 initialization first.
Or tuples.
Apr 01
prev sibling next sibling parent David Gileadi <gileadisNOSPM gmail.com> writes:
On 3/31/19 8:53 AM, Andre Pany wrote:
 I still have the opinion we should go for in place struct initialization 
 first. Here we get named parameters implicit without adding a complete 
 new syntax. I also do not like the new syntax <>.
 Leveraging what inplace struct initialization syntax gives us, seems a 
 lot more reasonable in my opinion.
 
 Kind regards
 Andre
I keep feeling like the in-place struct initialization proposal plus the syntax sugar described in its "Bonus 1"[1] would be perfect. It strikes me as very D-ish: clever, simple to explain, doesn't conflict with existing features, and allows the call-side things we want from named parameters like omitting arguments and/or providing them in any order, per existing rules for static initialization of structs [2]. [1]: https://github.com/dlang/DIPs/blob/b1283b455b635d7dcbc2c871d2aa47cc67190059/DIPs/DIP1xxx-sw.md#bonus-1-function-calls-with-the-struct-argument-as-sole-parameter [2]: https://dlang.org/spec/struct.html#static_struct_init
Apr 01
prev sibling parent Martin Tschierschke <mt smartdolphin.de> writes:
On Sunday, 31 March 2019 at 15:53:53 UTC, Andre Pany wrote:
 On Sunday, 31 March 2019 at 12:33:56 UTC, Mike Parker wrote:
 This is the feedback thread for the first round of Community 
 Review for DIP 1020, "Named Parameters":

 https://github.com/dlang/DIPs/blob/39dbbbe5e4618abd4c4b41eb0edd16547858ddf5/DIPs/DIP1020.md
[..]
 I still have the opinion we should go for in place struct 
 initialization first. Here we get named parameters implicit 
 without adding a complete new syntax. I also do not like the 
 new syntax <>.
 Leveraging what inplace struct initialization syntax gives us, 
 seems a lot more reasonable in my opinion.

 Kind regards
 Andre
Upvote +1! please no: <> !
Apr 05
prev sibling next sibling parent Olivier FAURE <couteaubleu gmail.com> writes:
On Sunday, 31 March 2019 at 12:33:56 UTC, Mike Parker wrote:
 This is the feedback thread for the first round of Community 
 Review for DIP 1020, "Named Parameters":

 https://github.com/dlang/DIPs/blob/39dbbbe5e4618abd4c4b41eb0edd16547858ddf5/DIPs/DIP1020.md
I'll be way more harsh than the other posters here, sorry in advance. Andrei was talking recently about how some contributions didn't have the level of quality required to be useful to a project; and how these contributions could have structural problems so deep, that no amount of incremental changes would fix them. As far as I can tell, this is one of them. I cannot imagine any version of this DIP being accepted, ever. - As the others have pointed out, the syntax is terrible. It could work in another language, but it's a very bad fit for D, and it looks too much like C++ templates, which are unrelated to named arguments. - The DIP doesn't consider alternative syntaxes. Named arguments in particular are a concept that can be executed in any numbers of ways, both at the declaration site and the call site. A strong proposal would need to list these potential ways, and why one of them is stronger than the others. The DIP points out that DIP-1019 exists, but doesn't make any comparison or give any reason to implement DIP-1020 over DIP-1019. - The rationale is extremely weak. "Other languages do X" and "People said we shouldn't do Y" isn't a valid rationale. A good rationale should detail why people want named arguments, and why other languages include them. The author should do some analysis work, to explain the deeper semantics of named arguments, why they are useful, their drawbacks, and why the current proposal best addresses these semantics while avoiding their drawbacks. Overall, my subjective feeling is that the DIP is closer to a shower-thought idea, than the result of a comprehensive analysis process. I don't get the feeling the author has spent enough time considering possible alternatives, complexity and maintenance cost, interoperability with existing semantics, etc. In fact, I don't think the author has spent a 10th of the time necessary to properly address these problems. So I don't think this DIP should make it anywhere past community review. (sorry)
Mar 31
prev sibling next sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
Thank you Richard for writing the DIP.

I subscribe to Olivier's review and won't repeat those critiques. In 
addition, I have the following concerns.

1) Any DIP on named arguments nowadays should have references to all 
prior suggestions and ideas, summarize them and categorize them and 
clarify why this one is better.

2) Different subjects should have different section headings ("Overload 
resolution", "Variadic parameters", etc).

3) What is the value of the following?

 The function call `func(1, 2, o:true)` is the same as `func(1, 
o:true, 2)` or `func(o:true, 1, 2)`. So is this equivalent at the definition site as well: `void func(int a, int b, <bool o>);`, `void func(int a, <bool o>, int b);` and `void func(<bool o>, int a, int b);`? Being able to reorder arguments somewhat but not any way you like is confusing. 4) The section on overload resolution is flawed because it contains illegal code:
 `void bar(int a, string b = "", int c) {}`
5) Use cases. The "Ranges" case needs to open with what the example looks like without the DIP, and then with the DIP, so that its value becomes apparent. So one of the advantages of this DIP is that fewer types and instantiations are needed? That is fundamental and should be further explained and certainly goes beyond syntax sugar or mere improvement of readability. What is necessary, compiler implementation wise, to support that? The "Logging" case (grouping of arguments that the user typically would not want to bother with) has nothing to do with named arguments as users won't typically name those arguments. 6) About the aim of the DIP:
 "The primary aim of this proposal is to aid in readability and the 
implementation of tooling." I have no idea how this DIP is supposed to aid in the implementation of tooling. There is no further mentioning of tooling at all. What is left is "aid readability" which I agree would be a worthwhile improvement. However, in this DIP, what is gained in readability at the call site is smaller in value than what is lost in readability at the definition site, to a net loss. The value in readability should be weighed against ordinary comments: `func(1, 2, o:true)` versus `func(1, 2, /*o*/ true)` Note that the comment has the added advantage that it is optional at the call site. This DIP should justify itself against the obvious solution which in my eyes is accepting `o:` in this example as a comment. It would be easy to accept an identifier followed by a colon in a parameter list as a new syntax for a comment. It would work everywhere and be optional. As an extra service, the compiler could check the comment against the function definition and issue a warning in case of a mismatch: "Warning: argument 3 of 'func' is not called 'o', did you mean 'q'?" or the like. Maybe this is worth a DIP? Bastiaan.
Mar 31
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 01/04/2019 11:22 AM, Bastiaan Veelo wrote:

 1) Any DIP on named arguments nowadays should have references to all 
 prior suggestions and ideas, summarize them and categorize them and 
 clarify why this one is better.
That is a major rabbit hole. I will accept a write up from somebody else, but I do not feel like its a good idea to go down it.
 3) What is the value of the following?
 
  > The function call `func(1, 2, o:true)` is the same as `func(1, 
 o:true, 2)` or `func(o:true, 1, 2)`.
As far as the assembly is concerned, yes.
 So is this equivalent at the definition site as well: `void func(int a, 
 int b, <bool o>);`, `void func(int a, <bool o>, int b);` and `void 
 func(<bool o>, int a, int b);`? Being able to reorder arguments somewhat 
 but not any way you like is confusing.
What matters is the relative ordering between the arguments. If the arguments are forced as per the declaration you lose the ability to express the call as the user sees fit. But if you go too loose you run into code smells and abuse. This is a lose-lose situation. Some people hate full reordering, some hate no reordering. There is no way to win. With partial reordering perhaps we can have a compromise instead.
 4) The section on overload resolution is flawed because it contains 
 illegal code:
 
  > `void bar(int a, string b = "", int c) {}`
Oof you are so correct. It should be: --- void foo(int a, <int c = 0>) {} void foo(int a, string b = "", <int c = 0>) {} void bar(int a) {} void bar(int a, string b = "") {} --- Does that make more sense now? (I'll update the DIP with the fix after review)
Apr 01
prev sibling next sibling parent reply =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
 ... this DIP does not allow arguments to be reordered. The primary aim 
 of this proposal is to aid in readability and the implementation of 
 tooling.
I don't see any value in the DIP, what do I gain? I can't re-order arguments, which would IMO be THE use-case for named parameters. Aid in readability by adding more syntax is counter productive. It lowers readability. I can add a comment where apropriate if necessary. Without a strong use-case and a clear argumentation about the benefits over current options, it is totally unclear why the DIP is necessary. -- Robert M. Mnch http://www.saphirion.com smarter | better | faster
Mar 31
parent FeepingCreature <feepingcreature gmail.com> writes:
On Monday, 1 April 2019 at 06:28:57 UTC, Robert M. Münch wrote:
 Aid in readability by adding more syntax is counter productive. 
 It lowers readability. I can add a comment where apropriate if 
 necessary.

 Without a strong use-case and a clear argumentation about the 
 benefits over current options, it is totally unclear why the 
 DIP is necessary.
I don't have an opinion on the relative merits of the DIP, I just want to voice why named arguments are useful - they allow you to *force* semantic coupling between the caller and the callee in a way that comments don't. As it stands, it is essentially impossible to determine the purpose of a parameter in a function call in many cases. `foo(sum)` tells you basically nothing about what `foo` actually wants the `sum` parameter *for*. If you could demand in code reviews that such cases used named parameters, you would end up with a much more pleasant expression such as `foo(iterationSteps: sum)`; simultaneously, the call to foo would be committed to a particular semantic interpretation of its parameter, such that `foo` could indicate that it had changed its meaning without being **forced,** as it currently is, to either change its type, go through an awkward deprecation/reimplementation cycle, or invite silent breakage on updates. Named parameters are a clear win for readability and maintainability, imo.
Apr 01
prev sibling next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
As the author of this DIP, I have created a list of actionable items I 
expect to include in the next iteration of the DIP.

If I have missed something you wish to be included please reply to this 
post.

In the next few days I expect to write a (short) set of responses so 
that we can discuss it further. My responses tonight will be directed at 
non-reoccurring items between the posts.

- Angle brackets, may be hard to find given relationship with templates
   Potential solutions include `` named``
- External access of template parameters externally needs justification
- Interaction with eponymous templates, invalid
- "Future proposals" sections should probably have a full rewrite to 
indicate its for recognizing desirable semantics that are out of scope.
- Not in competition with in place struct initialization, different purposes
- More headings (break down behavior)
- Reorder of arguments does not change at symbol site, only at the 
argument side
- Overload resolution code is flawed with illegal code
- Compare and contrast example code
- Logging case demonstrates that for functions unnamed should be the 
default API wise
- Duplicate naming is bad, flagging of a parameter as named is better
Apr 01
next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Monday, 1 April 2019 at 11:39:50 UTC, rikki cattermole wrote:
 As the author of this DIP, I have created a list of actionable 
 items I expect to include in the next iteration of the DIP.

 If I have missed something you wish to be included please reply 
 to this post.

 In the next few days I expect to write a (short) set of 
 responses so that we can discuss it further. My responses 
 tonight will be directed at non-reoccurring items between the 
 posts.
Thanks for doing this! Repeating myself:
Section "Use Cases" needs more explanation: I don't see how the 
ranges example revokes the need for ElementType, perhaps a
 "before and after" would be useful here
Apr 01
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 02/04/2019 12:50 AM, Nicholas Wilson wrote:
 On Monday, 1 April 2019 at 11:39:50 UTC, rikki cattermole wrote:
 As the author of this DIP, I have created a list of actionable items I 
 expect to include in the next iteration of the DIP.

 If I have missed something you wish to be included please reply to 
 this post.

 In the next few days I expect to write a (short) set of responses so 
 that we can discuss it further. My responses tonight will be directed 
 at non-reoccurring items between the posts.
Thanks for doing this! Repeating myself:
 Section "Use Cases" needs more explanation: I don't see how the ranges 
 example revokes the need for ElementType, perhaps a
 "before and after" would be useful here
Its in there :) - Compare and contrast example code
Apr 01
prev sibling parent reply Seb <seb wilzba.ch> writes:
On Monday, 1 April 2019 at 11:39:50 UTC, rikki cattermole wrote:
 As the author of this DIP, I have created a list of actionable 
 items I expect to include in the next iteration of the DIP.

 [...]
BTW are you aware of the recently accepted PEP 570 for Python [1]? It allows library authors optionally to control exactly which parameters are positional and which are keyword-only and which are both. [1] https://www.python.org/dev/peps/pep-0570/
Apr 09
next sibling parent reply aliak <something something.com> writes:
On Tuesday, 9 April 2019 at 19:46:47 UTC, Seb wrote:
 On Monday, 1 April 2019 at 11:39:50 UTC, rikki cattermole wrote:
 As the author of this DIP, I have created a list of actionable 
 items I expect to include in the next iteration of the DIP.

 [...]
BTW are you aware of the recently accepted PEP 570 for Python [1]? It allows library authors optionally to control exactly which parameters are positional and which are keyword-only and which are both. [1] https://www.python.org/dev/peps/pep-0570/
Can't say I'm a fan of the chosen syntax (also can't say I can think of anything better in python's case). But IMO they've got the motivation, rationale, and benefits down awesomely well. It's finally fixing (in theory) one of my personal sore points with python :D It's worth considering allowing API authors to control how their APIs ought to be called. I've never completely understood why reordering is a requirement for some from the caller's side. It doesn't really add anything in terms of readability or maintainability in my experience - in-fact it reduces them because consistency goes out the window. And I'm not sure how allowing all parameters to be called as named is going to help in anyway other than making API authors' lives harder in terms of maintenance costs:
Apr 09
parent reply Paul Backus <snarwin gmail.com> writes:
On 4/9/19 5:20 PM, aliak wrote:
 It's worth considering allowing API authors to control how their APIs
 ought to be called. I've never completely understood why reordering is a
 requirement for some from the caller's side. It doesn't really add
 anything in terms of readability or maintainability in my experience -
 in-fact it reduces them because consistency goes out the window. And I'm
 not sure how allowing all parameters to be called as named is going to
 help in anyway other than making API authors' lives harder in terms of
 maintenance costs:
 
If you have named arguments, and allow skipping over optional arguments, but *don't* allow reordering, you end up with some really silly-looking errors: // One of these calls will fail to compile spawnProcess("./do_stuff", stdout: outputFile, stderr: logFile); // This doesn't, because 'stdout' comes before 'stderr' spawnProcess("./do_stuff", stderr: logFile, stdout: outputFile); Would you rather (a) have to explain to new D users why the first one works and the second one doesn't, or (b) live with parameter reordering being allowed?
Apr 10
parent aliak <something something.com> writes:
On Wednesday, 10 April 2019 at 17:13:04 UTC, Paul Backus wrote:
 On 4/9/19 5:20 PM, aliak wrote:
 It's worth considering allowing API authors to control how 
 their APIs ought to be called. I've never completely 
 understood why reordering is a requirement for some from the 
 caller's side. It doesn't really add anything in terms of 
 readability or maintainability in my experience - in-fact it 
 reduces them because consistency goes out the window. And I'm 
 not sure how allowing all parameters to be called as named is 
 going to help in anyway other than making API authors' lives 
 harder in terms of maintenance costs:
 
If you have named arguments, and allow skipping over optional arguments, but *don't* allow reordering, you end up with some really silly-looking errors: // One of these calls will fail to compile spawnProcess("./do_stuff", stdout: outputFile, stderr: logFile); // This doesn't, because 'stdout' comes before 'stderr' spawnProcess("./do_stuff", stderr: logFile, stdout: outputFile); Would you rather (a) have to explain to new D users why the first one works and the second one doesn't, or (b) live with parameter reordering being allowed?
Most definitely a :) For a few reasons. 1) Semantic meaning: the semantic meaning that is present in the order of parameters matters in APIs (not always, but often enough). I.e. with algorithms in c++, the call sites would make you look twice and go "huh" if _end_ was passed before _begin_. So mentally, having to parse all these becomes a harder task: generate!int(start: 0, end: 10, stride: 2) vs generate!int(stride: 2, end: 10, start: 0) vs generate!int(end: 10, stride: 2, start: 0) vs 2) Learnability: Having fixed pos parameters is easier to learn because you consistently repeat the same pattern 3) Reduced mental anguish :p - ok I'm being a bit dramatic here and I have no data to back this up, but if I saw this: auto c = color(g=123, b=2, a=3, r=7) I personally, and I'm pretty sure I'd bet monies that any - or most - graphics engineers, would die just a weeeee little bit. 4) Consistency: allowing all the possible permutations of a function would just lead to inconsistent call sites. Consistent is usually better than inconsistent in any large code base. 5) Searchability: searching is possible - grepping or ctrl+f "function(firstName:" has helped me out *many* times. You could not rely on this if re-ordering is allowed. 6) What's so complicated about the explanation: "yeah you have to specify the arguments in order they're declared"? I've been using objective-c and then swift for the past 7 years now, and I haven't been confronted with the any kind of negativity associated to not being able to reorder arguments. Also: if named arguments are reorderable and optional, should we worry about this scenario - i'm not sure we should but just throwing out there as a thought: // User A writes code move(y=0, x=1) // User B comes at some point and decides variable names are good enough move(y, x) // and the actual function declaration is: move(int x, int y) For the record, I could live with either - but I have a preference for positional. I don't see the advantage of reordering though. Is it just to avoid not having to tell people that you need to specify arguments in the order they're declared? Is it because it's easier to write out the function call? Are there some technical advantages? Is it (much) easier to implement? Cheers, - Ali
Apr 10
prev sibling next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 10/04/2019 7:46 AM, Seb wrote:
 On Monday, 1 April 2019 at 11:39:50 UTC, rikki cattermole wrote:
 As the author of this DIP, I have created a list of actionable items I 
 expect to include in the next iteration of the DIP.

 [...]
BTW are you aware of the recently accepted PEP 570 for Python [1]? It allows library authors optionally to control exactly which parameters are positional and which are keyword-only and which are both. [1] https://www.python.org/dev/peps/pep-0570/
Its basically partial reordering as I described in this DIP. So yay one more reference!
Apr 09
prev sibling next sibling parent JN <666total wp.pl> writes:
On Tuesday, 9 April 2019 at 19:46:47 UTC, Seb wrote:
 On Monday, 1 April 2019 at 11:39:50 UTC, rikki cattermole wrote:
 As the author of this DIP, I have created a list of actionable 
 items I expect to include in the next iteration of the DIP.

 [...]
BTW are you aware of the recently accepted PEP 570 for Python [1]? It allows library authors optionally to control exactly which parameters are positional and which are keyword-only and which are both. [1] https://www.python.org/dev/peps/pep-0570/
Wow, that syntax looks bad. I like Dart's syntax for that: void enableFlags([bool foo]) {...} <- positional arg void enableFlags({bool foo}) {...} <- keyword arg void enableFlags({ required bool foo}) {...} <- required keyword arg
Apr 10
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/9/2019 12:46 PM, Seb wrote:
 It allows library authors optionally to control exactly which parameters are 
 positional and which are keyword-only and which are both.
 
 [1] https://www.python.org/dev/peps/pep-0570/
Note that there is a way to require positional-only in D: int foo(int); I.e. leave off the parameter name. It works when there's a separate .di file from the implementation .d file (which would have the names). It won't work for template parameters. As for renaming parameters, void foo(T oldname); becomes: void foo(T)(T oldname) { return foo(newname : oldname); } void foo(T newname); Yeah, it's a little awkward, but if you're renaming parameters you've got awkward backwards compatibility issues anyway.
Apr 10
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/10/19 4:03 PM, Walter Bright wrote:
 On 4/9/2019 12:46 PM, Seb wrote:
 It allows library authors optionally to control exactly which 
 parameters are positional and which are keyword-only and which are both.

 [1] https://www.python.org/dev/peps/pep-0570/
Note that there is a way to require positional-only in D:     int foo(int); I.e. leave off the parameter name. It works when there's a separate .di file from the implementation .d file (which would have the names). It won't work for template parameters. As for renaming parameters,     void foo(T oldname); becomes:     void foo(T)(T oldname) { return foo(newname : oldname); }     void foo(T newname); Yeah, it's a little awkward, but if you're renaming parameters you've got awkward backwards compatibility issues anyway.
Regarding reordering, here's a nice demo: https://youtu.be/G5SIwRinEYk?t=994 The presenter has a plot described like this: line3d(v, color='purple', thickness=3, spin=3) Then he nicely changes a parameter and the plot gets updated in near real-time. Also note how the call mixes positional with named arguments: the important/required one comes first, followed by optional ones. The ordering of named parameters does not matter, it's irrelevant whether the thickness comes before or after the color etc. Such usability advantages and concerns need to be front and center in a named parameter proposal.
Apr 17
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Sunday, 31 March 2019 at 12:33:56 UTC, Mike Parker wrote:
 This is the feedback thread for the first round of Community 
 Review for DIP 1020, "Named Parameters":
While I generally do not like the idea of named parameters for function calls, I will limit my feedback here to one part of the proposal:
 Arguments matching named parameters must be named arguments, 
 i.e. they must use the name:value syntax. Named arguments must 
 be passed to a function in the same order as the named 
 parameters with which they match appear in the parameter list, 
 but may be passed in any order relative to unnamed arguments. 
 Given the prototype:

 void func(int a, int b, <bool o>);

 The function call func(1, 2, o:true) is the same as func(1, 
 o:true, 2) or func(o:true, 1, 2).
It is unclear what we would gain from allowing this, and at the same time, it would make it extremely difficult for new users to the language to read code. Reordering unnamed parameters is a recipe for disaster. In some cases, the second argument is x, in some cases it is y, and in yet other cases, it is z. Was there are mistake when writing this:
 Named arguments must be passed to a function in the same order 
 as the named parameters with which they match appear in the 
 parameter list, but may be passed in any order relative to 
 unnamed arguments.
It makes sense to allow named arguments to appear out of order, but unnamed parameters should always have to appear in the same order as they are declared. It would really help to have an extensive set of examples demonstrating large benefits to implementation of this proposal. It is not a good idea to assume that everyone is familiar with all the details of named arguments, the various arguments for and against, or the alternatives that achieve the same thing. Ideally there should be something that named arguments provide that cannot reasonably be accomplished any other way.
Apr 01
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 02/04/2019 2:06 AM, bachmeier wrote:
 On Sunday, 31 March 2019 at 12:33:56 UTC, Mike Parker wrote:
 This is the feedback thread for the first round of Community Review 
 for DIP 1020, "Named Parameters":
While I generally do not like the idea of named parameters for function calls, I will limit my feedback here to one part of the proposal:
 Arguments matching named parameters must be named arguments, i.e. they 
 must use the name:value syntax. Named arguments must be passed to a 
 function in the same order as the named parameters with which they 
 match appear in the parameter list, but may be passed in any order 
 relative to unnamed arguments. Given the prototype:

 void func(int a, int b, <bool o>);

 The function call func(1, 2, o:true) is the same as func(1, o:true, 2) 
 or func(o:true, 1, 2).
It is unclear what we would gain from allowing this, and at the same time, it would make it extremely difficult for new users to the language to read code. Reordering unnamed parameters is a recipe for disaster. In some cases, the second argument is x, in some cases it is y, and in yet other cases, it is z. Was there are mistake when writing this:
 Named arguments must be passed to a function in the same order as the 
 named parameters with which they match appear in the parameter list, 
 but may be passed in any order relative to unnamed arguments.
It makes sense to allow named arguments to appear out of order, but unnamed parameters should always have to appear in the same order as they are declared.
You misunderstood :) Unnamed arguments must remain in the same order they are declared in. Named arguments must remain in the same order they are declared in, but they may be inserted in between unnamed arguments giving a partial reordering. I.e. void func(int a, <int b>, int c, <int d>) {} Valid: func(1, b: 2, d: 3, 4); Invalid: func(1, d: 2, c: 3, 4); Basically, if you split named and unnamed in the above example you would get two sets of parameter lists: int a, int c <int b>, <int d> As long as each parameter list stays in that order, it should be legal to be called/initialized. Does that answer your question/concerns?
Apr 01
parent reply bachmeier <no spam.net> writes:
On Monday, 1 April 2019 at 13:21:48 UTC, rikki cattermole wrote:

 Unnamed arguments must remain in the same order they are 
 declared in.

 Named arguments must remain in the same order they are declared 
 in, but they may be inserted in between unnamed arguments 
 giving a partial reordering.
That's the part that is going to cause major trouble for someone new to the language. Suppose you have this function: foo(int v, int w, int x, int y, int z) Then the call foo(3, 4, 5, 6, 7) is easy to understand, even if you have to know which order the arguments appear. But make x, y, and z named parameters, and you have foo(3, 4, x=5, y=6, z=7) foo(3, x=5, 4, y=6, z=7) foo(3, x=5, y=6, 4, z=7) foo(3, x=5, y=6, z=7, 4) all evaluating to the same thing, and somehow the programmer is supposed to know that the 4 is mapped to the second argument in every call. This is the kind of thing that would make someone give up on D after just a few minutes. The only way it can work to rearrange the mapping of parameters from the function call to the function itself is if the parameter being moved is named. This is a simple example. If you had several named and several unnamed parameters it would lead to a lot of confusion.
Apr 01
next sibling parent reply arturg <var.spool.mail700 gmail.com> writes:
On Monday, 1 April 2019 at 19:41:25 UTC, bachmeier wrote:
 On Monday, 1 April 2019 at 13:21:48 UTC, rikki cattermole wrote:

 [...]
That's the part that is going to cause major trouble for someone new to the language. Suppose you have this function: foo(int v, int w, int x, int y, int z) Then the call foo(3, 4, 5, 6, 7) is easy to understand, even if you have to know which order the arguments appear. But make x, y, and z named parameters, and you have foo(3, 4, x=5, y=6, z=7) foo(3, x=5, 4, y=6, z=7) foo(3, x=5, y=6, 4, z=7) foo(3, x=5, y=6, z=7, 4) all evaluating to the same thing, and somehow the programmer is supposed to know that the 4 is mapped to the second argument in every call. This is the kind of thing that would make someone give up on D after just a few minutes. The only way it can work to rearrange the mapping of parameters from the function call to the function itself is if the parameter being moved is named. This is a simple example. If you had several named and several unnamed parameters it would lead to a lot of confusion.
Whats the big issue with named parameters, why cant D have them with the same restriction as C#? foo(3, 4, x=5, y=6, z=7) works foo(3, x=5, 4, y=6, z=7) does'nt, because every paremeter after a named one has to be a named parameter
Apr 01
parent reply sarn <sarn theartofmachinery.com> writes:
On Monday, 1 April 2019 at 20:36:47 UTC, arturg wrote:
 Whats the big issue with named parameters, why cant D have them 
 with the same restriction as C#?

 foo(3, 4, x=5, y=6, z=7) works
 foo(3, x=5, 4, y=6, z=7) does'nt, because every paremeter after 
 a named one has to be a named parameter
+1 It's the same rule as in Python and others, and it works. Mixing positional/named parameters makes the call harder to read. (Think quick: which positional parameter does the 4 in the example refer to?) Reordering named parameters is useful because if the parameters are named, that probably means the names are more semantic than the ordering. Having to remember an arbitrary ordering just makes life more difficult.
Apr 01
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Apr 01, 2019 at 11:11:33PM +0000, sarn via Digitalmars-d wrote:
 On Monday, 1 April 2019 at 20:36:47 UTC, arturg wrote:
 Whats the big issue with named parameters, why cant D have them with
 the same restriction as C#?
 
 foo(3, 4, x=5, y=6, z=7) works
 foo(3, x=5, 4, y=6, z=7) does'nt, because every paremeter after a
 named one has to be a named parameter
+1 It's the same rule as in Python and others, and it works. Mixing positional/named parameters makes the call harder to read. (Think quick: which positional parameter does the 4 in the example refer to?) Reordering named parameters is useful because if the parameters are named, that probably means the names are more semantic than the ordering. Having to remember an arbitrary ordering just makes life more difficult.
Yeah, having named and unnamed parameters in mixed order doesn't make sense to me; it's just like having non-default arguments following default arguments -- makes code needlessly complicated and hard to read. It should be just a simple boolean state: the initial segment of an argument list is positional, with zero or more arguments, and the remainder of the argument list is named, with zero or more arguments. Once a named argument is encountered it's no longer grammatical to have a positional argument. Something along these lines: ArgumentList ::= PositionalArgs NamedArgs ; PositionalArgs ::= <empty list> | <expression> | <expression> "," PositionalArgs ; NamedArgs ::= <empty list> | <identifier> "=" <expression> | <identifier> "=" <expression> "," NamedArgs ; T -- Heads I win, tails you lose.
Apr 01
prev sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Monday, 1 April 2019 at 19:41:25 UTC, bachmeier wrote:
 [snip]
 all evaluating to the same thing, and somehow the programmer is 
 supposed to know that the 4 is mapped to the second argument in 
 every call. This is the kind of thing that would make someone 
 give up on D after just a few minutes. The only way it can work 
 to rearrange the mapping of parameters from the function call 
 to the function itself is if the parameter being moved is 
 named. This is a simple example.
In R, if you have f <- function(x, y, z) { x + 2*y + 3*z} and call f(z=1, 2, 3) the result is 11. I don't know if that's any easier or not, but I can definitely see how people would find a lot of these examples confusing.
Apr 01
prev sibling next sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Sunday, 31 March 2019 at 12:33:56 UTC, Mike Parker wrote:
 This is the feedback thread for the first round of Community 
 Review for DIP 1020, "Named Parameters":

 https://github.com/dlang/DIPs/blob/39dbbbe5e4618abd4c4b41eb0edd16547858ddf5/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 April 14, or when I make a post declaring it complete.

 At the end of Round 1, 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 by the language maintainers.

 Please familiarize yourself with the documentation for the 
 Community Review before participating.

 https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#community-review

 Thanks in advance to all who participate.
 Contrary to the implementation of this feature in other 
 languages, this DIP does not allow arguments to be reordered. 
 The primary aim of this proposal is to aid in readability and 
 the implementation of tooling.
To me, this removes the main reason for wanting this feature in the first place.
 To delineate a named parameter, the parameter declaration is 
 wrapped in angle brackets such that bool o is a standard, 
 unnamed parameter and <bool o> is a named parameter.
There are known reasons why using angle brackets complicates lexing (cough! C++! cough!), so the syntax choice is odd. Is there a particular reason why the usage suggested here avoids the issues?
Apr 01
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 02/04/2019 3:09 AM, Atila Neves wrote:
 There are known reasons why using angle brackets complicates lexing 
 (cough! C++! cough!), so the syntax choice is odd. Is there a particular 
 reason why the usage suggested here avoids the issues?
As far as I'm aware, we should have no problems with adapting dmd-fe to support it. Of course I could have missed something (either in dmd or outside). So it would be good to have somebody else double check that statement.
Apr 01
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/1/19 10:41 AM, rikki cattermole wrote:
 On 02/04/2019 3:09 AM, Atila Neves wrote:
 There are known reasons why using angle brackets complicates lexing 
 (cough! C++! cough!), so the syntax choice is odd. Is there a 
 particular reason why the usage suggested here avoids the issues?
As far as I'm aware, we should have no problems with adapting dmd-fe to support it. Of course I could have missed something (either in dmd or outside). So it would be good to have somebody else double check that statement.
I don't see one either, but then a lot of very smart people didn't see that a<b>(c) could mean both (a < b) > (c) and (a<b>)(c). Much more recently, many folks, even after having learned from the experience just mentioned, didn't realize that a.operator<=>(b) could mean both (a.operator<=) > (b) and (a.operator<=>)(b). At any rate, this is unlikely to win a beauty contest: void fun(<bool a=b>c>); Also, it seems named parameters without reordering is like a wedding without music.
Apr 01
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 02/04/2019 8:03 AM, Andrei Alexandrescu wrote:
 
 At any rate, this is unlikely to win a beauty contest:
 
 void fun(<bool a=b>c>);
Indeed. Hence I'm open to alternatives if we can find a good one. Its a hard syntax to come up with while keeping it consistent with all the current semantics.
 Also, it seems named parameters without reordering is like a wedding 
 without music.
We have three schools of thought in the D community. In around equal shares is those who think reordering is bad, and another who think its great. Finally there is also those who don't care much. Which I think take the larger portion. I'm trying to find a balance between the three. None of the schools of thought seem to win out. They each have their pros and cons. But I'm in the belief that I have struck a good middle ground that gives us the chance later on to either restrict or loosen once we have gotten some experience with it.
Apr 01
prev sibling parent reply sarn <sarn theartofmachinery.com> writes:
On Monday, 1 April 2019 at 14:41:20 UTC, rikki cattermole wrote:
 On 02/04/2019 3:09 AM, Atila Neves wrote:
 There are known reasons why using angle brackets complicates 
 lexing (cough! C++! cough!), so the syntax choice is odd. Is 
 there a particular reason why the usage suggested here avoids 
 the issues?
As far as I'm aware, we should have no problems with adapting dmd-fe to support it. Of course I could have missed something (either in dmd or outside). So it would be good to have somebody else double check that statement.
You already have to deal with the case of variadic function definitions, so why not just extend the syntax? I.e., in this declaration void foo(int a, int b, ..., int c); c must be a named argument, even without any special decorators. In that case the ... argument acts as a delimiter. So all you need is rules for separating positional arguments from named arguments for non-variadic functions.
Apr 01
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 02/04/2019 12:22 PM, sarn wrote:
 On Monday, 1 April 2019 at 14:41:20 UTC, rikki cattermole wrote:
 On 02/04/2019 3:09 AM, Atila Neves wrote:
 There are known reasons why using angle brackets complicates lexing 
 (cough! C++! cough!), so the syntax choice is odd. Is there a 
 particular reason why the usage suggested here avoids the issues?
As far as I'm aware, we should have no problems with adapting dmd-fe to support it. Of course I could have missed something (either in dmd or outside). So it would be good to have somebody else double check that statement.
You already have to deal with the case of variadic function definitions, so why not just extend the syntax? I.e., in this declaration void foo(int a, int b, ..., int c); c must be a named argument, even without any special decorators. In that case the ... argument acts as a delimiter.  So all you need is rules for separating positional arguments from named arguments for non-variadic functions.
Looks like a good idea, although a poor choice for this DIP. It could only work for function parameters, it won't work for templates. I don't think I've seen this idea come up before, so please do explore it if we don't get another solution in before hand!
Apr 01
parent Meta <jared771 gmail.com> writes:
On Tuesday, 2 April 2019 at 00:49:08 UTC, rikki cattermole wrote:
 On 02/04/2019 12:22 PM, sarn wrote:
 On Monday, 1 April 2019 at 14:41:20 UTC, rikki cattermole 
 wrote:
 On 02/04/2019 3:09 AM, Atila Neves wrote:
 There are known reasons why using angle brackets complicates 
 lexing (cough! C++! cough!), so the syntax choice is odd. Is 
 there a particular reason why the usage suggested here 
 avoids the issues?
As far as I'm aware, we should have no problems with adapting dmd-fe to support it. Of course I could have missed something (either in dmd or outside). So it would be good to have somebody else double check that statement.
You already have to deal with the case of variadic function definitions, so why not just extend the syntax? I.e., in this declaration void foo(int a, int b, ..., int c); c must be a named argument, even without any special decorators. In that case the ... argument acts as a delimiter.  So all you need is rules for separating positional arguments from named arguments for non-variadic functions.
Looks like a good idea, although a poor choice for this DIP. It could only work for function parameters, it won't work for templates. I don't think I've seen this idea come up before, so please do explore it if we don't get another solution in before hand!
Is it possible to lex the "public" keyword unambiguously when applied to parameters? long foo(int v, int w, int x, public int y, public int z) foo(1, 2, 3, y: 4, z:5); Many named args proposals for Rust propose this syntax. Another alternative is `export` on parameters. Or, something a little more interesting, but with unknown ramifications and possibly insane: //z is a named parameter with a default value long foo(int v, int w, int x, struct optargs { int y, int z = 3 }) foo(1, 2, 3, { y: 4 }); foo(1, 2, 3, { y: 4, z: 5 }); foo(1, 2, 3, optargs { y: 4, z: 5 }); foo(1, 2, 3, optargs { 4, 5 }); foo(1, 2, 3, { z: 5 }); //Error: cannot call function foo(int, int, int, struct optargs { int y, int z = 3 }) with arguments (1, 2, 3, { z: 5 }). Missing non-optional parameter y in optargs Just channeling the old struct DIP. I have no idea if this can even be lexed unambiguously.
Apr 01
prev sibling next sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Sunday, 31 March 2019 at 12:33:56 UTC, Mike Parker wrote:
 This is the feedback thread for the first round of Community 
 Review for DIP 1020, "Named Parameters":

 https://github.com/dlang/DIPs/blob/39dbbbe5e4618abd4c4b41eb0edd16547858ddf5/DIPs/DIP1020.md
Well. Do we have no other choice than that syntax? Happy about no-reordering here.
Apr 01
prev sibling next sibling parent Dukc <ajieskola gmail.com> writes:
On Sunday, 31 March 2019 at 12:33:56 UTC, Mike Parker wrote:
 This is the feedback thread for the first round of Community 
 Review for DIP 1020, "Named Parameters":

 https://github.com/dlang/DIPs/blob/39dbbbe5e4618abd4c4b41eb0edd16547858ddf5/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 April 14, or when I make a post declaring it complete.

 At the end of Round 1, 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 by the language maintainers.

 Please familiarize yourself with the documentation for the 
 Community Review before participating.

 https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#community-review

 Thanks in advance to all who participate.
I think this must go to formal assessment together with DIP1019 (named arguments lite). In fact, these two DIPs are close enough that you could consider merging them together. What I prefer about DIP1019 is the syntax, and the fact that you can reorder arguments. However, I'd like to keep the ability from this DIP to combine unnamed parameters with named ones. I propose that you let the caller to reorder named parameters freely. It should not cause complications, because they do not affect the overloading resolution anyway. Internally, the compiler could order named parameters alphabetically. Add that to a better syntax, and it starts to sound tempting.
Apr 03
prev sibling next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
This is my follow up reply, with my responses to common questions and 
points raised in this review as well as an updated copy of my actionable 
points list.

It took slightly longer than I expected, so apologies for that.

TLDR: I will be adding an alternative syntax as well as options for full 
and no reordering of arguments to the DIP following this review.

The current (final?) list of actionable points is as follows:

- Angle brackets, may be hard to find given relationship with templates
   Potential solutions include `` named``
- External access of template parameters externally needs justification
- Interaction with eponymous templates, invalid
- "Future proposals" sections should probably have a full rewrite to 
indicate its for recognizing desirable semantics that are out of scope.
- Not in competition with in place struct initialization, different purposes
- More headings (break down behavior)
- Reorder of arguments does not change at symbol site, only at the 
argument side
- Overload resolution code is flawed with illegal code
- Compare and contrast example code
- Logging case demonstrates that for functions unnamed should be the 
default API wise
- Duplicate naming is bad, flagging of a parameter as named is better
- Partial reordering needs examples!
- Angle bracket syntax will have problems if the parser doesn't peek one 
token ahead of >.
- Partial reordering why?

The list of questions I have answered is:

- Angle brackets, may be hard to find given relationship with templates
- External access of template parameters externally needs justification
- Interaction with eponymous templates, invalid
- Not in competition with in place struct initialization, different purposes
- Reorder of arguments does not change at symbol site, only at the 
argument side
- Partial reordering why?

If there is a question that I didn't end up answering, please do give me 
a ping, I did intend to have given a response to everything at this 
point in time.

A copy of the responses and the above list can be found here: 
https://gist.github.com/rikkimax/e9bee9fd1704aab1dcb1dafc26d3207d

As always, if I have forgotten something please let me know!










# Angle brackets, may be hard to find given relationship with templates

Agreed.

The angle bracket syntax was chosen in the current iteration of the DIP 
because it satisfies these criteria:

1. For a type on template parameters without the curved brackets (the 
only reason I indulged this requirement is because of the keyword)
2. As template parameters
3. As function parameters
4. Opt-in, easy to convert to and from
5. Consistent between all the above points

Alternative designs including the usage of `` named`` attribute is 
desirable, but require further research.

So far any attempt to satisfy these requirements has failed.
All other characters that have both an open and a close pair on regular 
keyboards are already in use by D in respect to types.
Overloading their usage further in the same design space would cause 
more harm than good.

The first point is a feature I want, which cannot be meet in using the 
`` named`` attribute design. Alas, perfect is the enemy of good, which 
means I'm going to have to compromise and remove it for other potential 
designs.

After some research into dmd.parse.d, the angle bracket syntax will 
require peeking into the next token when finding a '>' character as part 
of expression parsing. If the next token is valid for an expression 
instead of comma or closed bracket, then expression else end of named 
parameter definition. This complication makes this syntax less than 
desirable although not a blocker. Which confirms that yes alternative 
designs certainly should be considered.

# External access of template parameters externally needs justification

After further research, I can confirm that I cannot find any examples of 
named parameters being used as a first class citizens of 
meta-programming similar to what D has. This means that any work towards 
named template parameters must evolve from what we have already got.

Template parameters whose name has not been specified as part of their 
argument list demonstrate that their purpose is internal to the type and 
results in minimal concern to the initializer. Not all cases will appear 
this way. For example a type specified as the first argument on a data 
structure would imply that it is the type of the data being stored. But 
a boolean following it to enable GC interactions does not explain what 
it is there for hence why std.typecons.Flag exists.

For best effect a named template parameter is a subset of template 
parameters that the initializer has specifically set beyond the standard 
unnamed set. Because the initializer specifically requested it (or could 
in the future), it must therefore care about its value even if it has 
not been set. Being able to access this value without the usage of the 
is expression to extract it, demonstrates that it is part of the 
behavior that the type exhibits.

The above conclusions are the basis for my decision to expose a named 
template parameter as a member.

# Interaction with eponymous templates, invalid

The current logic is that if a template parameter name matches the 
template's, it will not act as a eponymous template. This should extend 
to named template parameters as well.

The spec makes it clear that template parameters cannot make an 
eponymous template.

"If a template contains members whose name is the same as the template 
identifier": yes, a named template parameter is visible as a member, but 
it should not be a member in the AST
"and if the type or the parameters type of these members include at 
least all the template parameters then these members are assumed to be 
referred to in a template instantiation:": potentially no

The semantics are uncharged by the DIP. I.e. named template parameters 
should not appear in a __traits(allMembers, T) request.

# Not in competition with in place struct initialization, different purposes

The facilitation of passing of arguments to a given function/template is 
done by either a named or unnamed parameter. In place struct 
initialization provides domain objects a way to be easily constructed 
and passed via one of the parameters. Individually an in place struct 
initialization syntax would be capable of emulating named arguments if 
you are willing to access and define a struct which is the parameter list.

Consider:

```d
void myFunction(Rect, <bool myFlag=false>) {}
myFunction({x: 1, y: 1, width: 9, height: 9}, myFlag: true);
```

In the function call the position and size is grouped as a domain object 
keeping the values together. Without in place struct initialization they 
will be separate in the arguments list and could potentially be not 
together with full reordering enabled. Which is poor programming.
The flag could be an unnamed argument as well. But then you couldn't put 
it at the start or move it around in the arguments list as appropriate.
If the flag, size and position arguments are stored in a struct, without 
using multiple layers of in place struct initialization you would not be 
keeping the domain objects together.

These two language features do not subtract from each other. They can be 
used to complement, with a well designed API.

# Reorder of arguments does not change at symbol site, only at the 
argument side

When a function with named parameters is compiled, its parameter order 
is fixed. The ordering in the argument list will be altered to match the 
parameters of the function. It does not matter what order the caller 
chose as long as it is valid.

The exact order of the arguments being passed to a function has not been 
defined as of yet. But because this is an extern(D) only feature, what 
is chosen should not be of concern to non-compiler developers and can be 
changed freely without error. The same can be said about template 
named+unnamed parameter order.

# Partial reordering why?

There are three philosophies of thought about ordering of named 
arguments that I have found so far.

1. Full
2. None
3. Some form of partial

Full and none have very vocal groups in the D programming language 
community. Each philosophy has its advantages and disadvantages. With 
many a bad code written and abused of this feature in either camp. The 
'default' option this DIP will offer is a partial reordering that does 
not restrict to the placement of the start of the named arguments or 
where the unnamed arguments end. The strong requirement of order between 
the named arguments that must match relatively to the parameters that 
they match to, exists to prevent full reordering. It is a sane default 
but does have the weakness that the order the parameters are defined it 
may not be suitable for the user.

If at some point the option desired changes, the change could be very 
breaking or it could be minimal in damages:

- To convert partial to full would require removing of code in a 
frontend. No breakage.
- To convert partial to none would require adding of code in the 
frontend. Breakage but it could be a deprecation warning followed by an 
error.
- To convert full to none would require adding of code in the frontend 
with significant breakage.
- To convert none to full would require removing of code in the frontend 
with no breakage.

For functions full is a clear winner for argument reordering, giving 
minimal restrictions and maximum use cases. But for template parameters 
it is not so clear cut. As per "External access of template parameters 
externally needs justification" we do not have the evidence to support 
what behavior is desirable at this point in time. Being conservative at 
the current time seems to be best way forward until we have experience 
with this potential language feature.
Apr 04
prev sibling next sibling parent reply Q. Schroll <qs.il.paperinik gmail.com> writes:
On Sunday, 31 March 2019 at 12:33:56 UTC, Mike Parker wrote:
 This is the feedback thread for the first round of Community 
 Review for DIP 1020, "Named Parameters":

 https://github.com/dlang/DIPs/blob/39dbbbe5e4618abd4c4b41eb0edd16547858ddf5/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 April 14, or when I make a post declaring it complete.

 At the end of Round 1, 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 by the language maintainers.

 Please familiarize yourself with the documentation for the 
 Community Review before participating.

 https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#community-review

 Thanks in advance to all who participate.
There are a couple of versions a parameter in a function can be syntactically appear: void f(int param = 0); // named with default value void f(int param); // named without default value void f(int = 0); // unnamed with default value void f(int); // unnamed without default value Named arguments must be compatible with at least the named variants. It must not be disturbed by the others. A bigger issue are template arguments -- here the variety is even bigger: template t(T) { } template t(T : S) { } // * template t(T = int) { } template t(T : S = int) { } plus any value parameter (see above) alias parameters probably can be handled as if `alias` were the type in the value parameter case. The starred one indicates that the colon is a nontrivial option for named arguments. First, it must not interfere with the type-colon, and it must be clear enough for programmers reading the code. I strongly believe that the most viable solution is a new token := which should be used at caller and/or callee site. Like: void f(int param = 0 := arg); f(arg := value); It's obviously compatible with anything and reads nicely. In fact, Visual Basic uses this at call site. 1. Should the callee have to specify argument names to make calling with named arguments possible? I don't know. 2. Should multiple namings be possible, i.e. overload by argument name? No. Name the function differently. 3. Should reordering be possible? If ever, only if *all* parameters are named and naming at call site necessary. 4. Should we wait until struct initialization? Yes. It can solve much of that.
Apr 04
parent Andre Pany <andre s-e-a-p.de> writes:
On Friday, 5 April 2019 at 00:17:02 UTC, Q. Schroll wrote:
 On Sunday, 31 March 2019 at 12:33:56 UTC, Mike Parker wrote:
 [...]
There are a couple of versions a parameter in a function can be syntactically appear: [...]
If we really want to go for a new named parameter syntax your syntax proposal looks the most reasonable so far. 1 no 2. I do not know 3. Yes. I would add following rule: after the first named argument, only named arguments can follow 4. Yes Still thinking the struct initialization dip will cover 80% of the named parameter use case. Kind regards Andre
Apr 05
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/31/2019 5:33 AM, Mike Parker wrote:
 This is the feedback thread for the first round of Community Review for DIP 
 1020, "Named Parameters":
Here's a much simpler proposal, based on the recognition that D already has named parameters: https://dlang.org/spec/struct.html#static_struct_init and related: https://dlang.org/spec/hash-map.html#static_initialization https://dlang.org/spec/arrays.html#static-init-static The only additional syntax would be allowing the equivalent of https://dlang.org/spec/hash-map.html#static_initialization in the argument list. Assignment of arguments to parameters would work the same way as assignments to fields. As for the semantics, given this constraint, nothing needs to be invented, just discovered as necessary behavior. Consider: void snoopy(T t, int i, S s); // A void snoopy(S s, int i = 0; T t); // B and calling it: S s; T t; int i; snoopy(t, i, s); // A snoopy(s, i, t); // B snoopy(s, t); // error, neither A nor B match snoopy(t, s); // error, neither A nor B match snoopy(s:s, t:t, i:i); // error, ambiguous snoopy(s:s, t:t); // B snoopy(t:t, s:s); // B snoopy(t:t, i, s:s); // A snoopy(s:s, t:t, i); // A I.e. function resolution is done by constructing an argument list separately for each function before testing it for matching. Of course, if the parameter name(s) don't match, the function doesn't match. If a parameter has no corresponding argument, and no default value, then the function doesn't match. I don't see much point in requiring the names, preventing use of names, nor aliasing them. This has never been an issue for struct initializers. One nice thing about this is the { } struct initialization syntax can be deprecated, as S(a:1, b:2) can replace it, and would be interchangeable with constructor syntax, making for a nice unification. (Like was done for array initialization.) One issue would be order of evaluation: would the arguments be evaluated in the lexical order of the arguments, or the lexical order of the parameters? 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. A secondary reason is (again) for a longish list of parameters, when the user finds himself counting parameters to ensure they line up, then named parameters can be most helpful.
Apr 06
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
That solves function arguments, what is your proposal for templates?
Apr 07
parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/7/2019 1:31 AM, rikki cattermole wrote:
 That solves function arguments, what is your proposal for templates?
Same problem, same solution.
Apr 07
prev sibling next sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Sunday, 7 April 2019 at 03:09:23 UTC, Walter Bright wrote:
 On 3/31/2019 5:33 AM, Mike Parker wrote:
 [...]
Here's a much simpler proposal, based on the recognition that D already has named parameters: [...]
This is really great, as there is also a DIP by Sebastian which goes into the same direction as you proposed. https://github.com/wilzbach/DIPs/blob/3068c4bfff44063ad34825baf8c35906c5ad787c/DIPs/DIP1xxx-sw.md The DIP is a little bit broader, S(a:1, b:2) should be usuable at more places too. Kind regards Andre
Apr 07
parent reply Daniel N <no public.email> writes:
On Sunday, 7 April 2019 at 08:48:44 UTC, Andre Pany wrote:
 On Sunday, 7 April 2019 at 03:09:23 UTC, Walter Bright wrote:
 On 3/31/2019 5:33 AM, Mike Parker wrote:
 [...]
Here's a much simpler proposal, based on the recognition that D already has named parameters: [...]
This is really great, as there is also a DIP by Sebastian which goes into the same direction as you proposed. https://github.com/wilzbach/DIPs/blob/3068c4bfff44063ad34825baf8c35906c5ad787c/DIPs/DIP1xxx-sw.md The DIP is a little bit broader, S(a:1, b:2) should be usuable at more places too. Kind regards Andre
Walter's idea correctly handles default arguments unlike the DIP you linked.
Apr 07
parent reply AltFunction1 <af1af1af1 af1.af1> writes:
On Sunday, 7 April 2019 at 08:58:36 UTC, Daniel N wrote:
 On Sunday, 7 April 2019 at 08:48:44 UTC, Andre Pany wrote:
 On Sunday, 7 April 2019 at 03:09:23 UTC, Walter Bright wrote:
 On 3/31/2019 5:33 AM, Mike Parker wrote:
 [...]
Here's a much simpler proposal, based on the recognition that D already has named parameters: [...]
This is really great, as there is also a DIP by Sebastian which goes into the same direction as you proposed. https://github.com/wilzbach/DIPs/blob/3068c4bfff44063ad34825baf8c35906c5ad787c/DIPs/DIP1xxx-sw.md The DIP is a little bit broader, S(a:1, b:2) should be usuable at more places too. Kind regards Andre
Walter's idea correctly handles default arguments unlike the DIP you linked.
I would not call this an idea. This is rather an evidence based on observation of the nature... I don't care personally about the feature but what does really worry me is that things like ` named` or any other syntactic changes tend to turn D into an incoherent language. The problem is that someone needs to write the correct proposal. IIRC Bright is not pro named argument and he said that he needs a solid DIP to be convinced.
Apr 07
parent reply bauss <jj_1337 live.dk> writes:
On Sunday, 7 April 2019 at 10:00:04 UTC, AltFunction1 wrote:
 I don't care personally about the feature but what does really 
 worry me is that things like ` named` or any other syntactic 
 changes tend to turn D into an incoherent language.
The day that named arguments has to have a special syntax in the function definition is the day I will quit using D tbh.
Apr 07
parent Daniel N <no public.email> writes:
On Sunday, 7 April 2019 at 12:35:34 UTC, bauss wrote:
 On Sunday, 7 April 2019 at 10:00:04 UTC, AltFunction1 wrote:
 I don't care personally about the feature but what does really 
 worry me is that things like ` named` or any other syntactic 
 changes tend to turn D into an incoherent language.
The day that named arguments has to have a special syntax in the function definition is the day I will quit using D tbh.
Well, walter is on the same page. Walter: "I don't see much point in requiring the names, preventing use of names, nor aliasing them. This has never been an issue for struct initializers." So you probably don't have to worry about that.
Apr 07
prev sibling parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
On Sunday, 7 April 2019 at 03:09:23 UTC, Walter Bright wrote:
 On 3/31/2019 5:33 AM, Mike Parker wrote:
 [...]
Here's a much simpler proposal, based on the recognition that D already has named parameters: [...]
I thought people don't like opt-ins. Yet this DIP, your proposal, and several other proposals in this thread are all opt-in. Am I allowed to include the named attribute in my DIP now? :)
Apr 07
parent reply Paul Backus <snarwin gmail.com> writes:
On Sunday, 7 April 2019 at 13:48:09 UTC, Yuxuan Shui wrote:
 On Sunday, 7 April 2019 at 03:09:23 UTC, Walter Bright wrote:
 On 3/31/2019 5:33 AM, Mike Parker wrote:
 [...]
Here's a much simpler proposal, based on the recognition that D already has named parameters: [...]
I thought people don't like opt-ins. Yet this DIP, your proposal, and several other proposals in this thread are all opt-in. Am I allowed to include the named attribute in my DIP now? :)
Walter's proposal isn't opt-in. The declarations of `snoopy` in his example are just regular D function declarations; there's nothing special added to them to enable the use of named arguments. This is, I think, conclusive evidence against the proposition that "W&A will only accept an extremely conservative, opt-in version of named arguments." So any further defense of syntax like DIP 1019's named or DIP 1020's angle brackets will have to be based on their actual merits, rather than on the mistaken idea that they will make a DIP more likely to be accepted.
Apr 07
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/7/19 10:25 AM, Paul Backus wrote:
 On Sunday, 7 April 2019 at 13:48:09 UTC, Yuxuan Shui wrote:
 On Sunday, 7 April 2019 at 03:09:23 UTC, Walter Bright wrote:
 On 3/31/2019 5:33 AM, Mike Parker wrote:
 [...]
Here's a much simpler proposal, based on the recognition that D already has named parameters: [...]
I thought people don't like opt-ins. Yet this DIP, your proposal, and several other proposals in this thread are all opt-in. Am I allowed to include the named attribute in my DIP now? :)
Walter's proposal isn't opt-in. The declarations of `snoopy` in his example are just regular D function declarations; there's nothing special added to them to enable the use of named arguments. This is, I think, conclusive evidence against the proposition that "W&A will only accept an extremely conservative, opt-in version of named arguments." So any further defense of syntax like DIP 1019's named or DIP 1020's angle brackets will have to be based on their actual merits, rather than on the mistaken idea that they will make a DIP more likely to be accepted.
Indeed. Probably a more accurate way to put it is "W&A will only accept /good/ ideas for named arguments (or anything else really)", which, however, is too general to be informative. Walter's idea is in the same category as the "a line of code where most others would need one hundred" I was alluding to. It is, in fact, so simple it's liable to be misunderstood. "This can't be so simple, there's got to be some opt-in trick somewhere".
Apr 07
prev sibling parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
On Sunday, 7 April 2019 at 14:25:43 UTC, Paul Backus wrote:
 On Sunday, 7 April 2019 at 13:48:09 UTC, Yuxuan Shui wrote:
 On Sunday, 7 April 2019 at 03:09:23 UTC, Walter Bright wrote:
 On 3/31/2019 5:33 AM, Mike Parker wrote:
 [...]
Here's a much simpler proposal, based on the recognition that D already has named parameters: [...]
I thought people don't like opt-ins. Yet this DIP, your proposal, and several other proposals in this thread are all opt-in. Am I allowed to include the named attribute in my DIP now? :)
Walter's proposal isn't opt-in. The declarations of `snoopy` in his example are just regular D function declarations; there's nothing special added to them to enable the use of named arguments.
Yeah. Sorry, I misread the proposal. The only problem I can see for now is that this proposal seems to mandate the inclusion of parameter names in mangled name of functions. Which makes name changes not only API breakages, but also ABI breakages.
Apr 07
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/7/2019 10:14 AM, Yuxuan Shui wrote:
 this proposal seems to mandate the 
 inclusion of parameter names in mangled name of functions.
Nope.
Apr 07
parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
On Sunday, 7 April 2019 at 21:19:20 UTC, Walter Bright wrote:
 On 4/7/2019 10:14 AM, Yuxuan Shui wrote:
 this proposal seems to mandate the inclusion of parameter 
 names in mangled name of functions.
Nope.
OK, I probably misunderstood, but what happens in the following case? void fun(int a, int b) {...} void fun(int c, int d) {...} fun(c:1, d:1); Is it ambiguous? Or does it invoke the second function? If the latter, then you have to include the parameter names in mangled name.
Apr 08
next sibling parent reply Daniel N <no public.email> writes:
On Monday, 8 April 2019 at 10:10:14 UTC, Yuxuan Shui wrote:
 On Sunday, 7 April 2019 at 21:19:20 UTC, Walter Bright wrote:
 On 4/7/2019 10:14 AM, Yuxuan Shui wrote:
 this proposal seems to mandate the inclusion of parameter 
 names in mangled name of functions.
Nope.
OK, I probably misunderstood, but what happens in the following case? void fun(int a, int b) {...} void fun(int c, int d) {...} fun(c:1, d:1); Is it ambiguous? Or does it invoke the second function? If the latter, then you have to include the parameter names in mangled name.
The compiler will directly reject... void fun(int a, int b) {...} void fun(int c, int d) {...} ... before you even try to call 'fun'.
Apr 08
parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
On Monday, 8 April 2019 at 10:41:25 UTC, Daniel N wrote:
 On Monday, 8 April 2019 at 10:10:14 UTC, Yuxuan Shui wrote:
 On Sunday, 7 April 2019 at 21:19:20 UTC, Walter Bright wrote:
 On 4/7/2019 10:14 AM, Yuxuan Shui wrote:
 this proposal seems to mandate the inclusion of parameter 
 names in mangled name of functions.
Nope.
OK, I probably misunderstood, but what happens in the following case? void fun(int a, int b) {...} void fun(int c, int d) {...} fun(c:1, d:1); Is it ambiguous? Or does it invoke the second function? If the latter, then you have to include the parameter names in mangled name.
The compiler will directly reject... void fun(int a, int b) {...} void fun(int c, int d) {...} ... before you even try to call 'fun'.
Contrary to popular belief, it won't. https://d.godbolt.org/z/Bmc-Qb
Apr 08
parent reply ShadoLight <ettienne.gilbert gmail.com> writes:
On Monday, 8 April 2019 at 12:01:39 UTC, Yuxuan Shui wrote:

[..]


 The compiler will directly reject...

 void fun(int a, int b) {...}
 void fun(int c, int d) {...}

 ...  before you even try to call 'fun'.
Contrary to popular belief, it won't. https://d.godbolt.org/z/Bmc-Qb
In line with popular belief it will. Try calling 1 of the 2 functions i.e.: int x = fun(3,4); You have to call one of them for the compiler to be (un)able to resolve the call.
Apr 08
parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
On Monday, 8 April 2019 at 13:11:51 UTC, ShadoLight wrote:
 On Monday, 8 April 2019 at 12:01:39 UTC, Yuxuan Shui wrote:

 [..]


 The compiler will directly reject...

 void fun(int a, int b) {...}
 void fun(int c, int d) {...}

 ...  before you even try to call 'fun'.
Contrary to popular belief, it won't. https://d.godbolt.org/z/Bmc-Qb
In line with popular belief it will. Try calling 1 of the 2 functions i.e.: int x = fun(3,4); You have to call one of them for the compiler to be (un)able to resolve the call.
Yes. But the post I was replying to says: "The compiler will directly reject... before you even try to call 'fun'.", which is not true.
Apr 08
parent ShadoLight <ettienne.gilbert gmail.com> writes:
On Monday, 8 April 2019 at 13:31:24 UTC, Yuxuan Shui wrote:
 On Monday, 8 April 2019 at 13:11:51 UTC, ShadoLight wrote:
 On Monday, 8 April 2019 at 12:01:39 UTC, Yuxuan Shui wrote:

 [..]


 The compiler will directly reject...

 void fun(int a, int b) {...}
 void fun(int c, int d) {...}

 ...  before you even try to call 'fun'.
Contrary to popular belief, it won't. https://d.godbolt.org/z/Bmc-Qb
In line with popular belief it will. Try calling 1 of the 2 functions i.e.: int x = fun(3,4); You have to call one of them for the compiler to be (un)able to resolve the call.
Yes. But the post I was replying to says: "The compiler will directly reject... before you even try to call 'fun'.", which is not true.
Yes, I agree he could have stated that better. But I'm pretty sure he meant something like "the compiler will directly reject... _once_ you even try to call 'fun'" or similar. BTW, this is the same in C++.
Apr 08
prev sibling parent reply bauss <jj_1337 live.dk> writes:
On Monday, 8 April 2019 at 10:10:14 UTC, Yuxuan Shui wrote:
 On Sunday, 7 April 2019 at 21:19:20 UTC, Walter Bright wrote:
 On 4/7/2019 10:14 AM, Yuxuan Shui wrote:
 this proposal seems to mandate the inclusion of parameter 
 names in mangled name of functions.
Nope.
OK, I probably misunderstood, but what happens in the following case? void fun(int a, int b) {...} void fun(int c, int d) {...} fun(c:1, d:1); Is it ambiguous? Or does it invoke the second function? If the latter, then you have to include the parameter names in mangled name.
That wouldn't work because the compiler would reject your function definitions when you attempt to call either of them because they're ambiguous. Just like it is today. Basically you could look at them just being: void fun(int,int); void fun(int,int); When you call a function like: void fun(int a, int b); ... fun(a: 1, b: 2); the compiler would really just reorder the passed values to match the parameters (If they can be specified in any order, if not then it will just them as it is. Which means: fun(a: 1, b: 2); becomes: fun(1, 2); and by then it should be clear why it wouldn't be allowed nor would work at all.
Apr 08
parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
On Monday, 8 April 2019 at 13:31:48 UTC, bauss wrote:
 On Monday, 8 April 2019 at 10:10:14 UTC, Yuxuan Shui wrote:
 On Sunday, 7 April 2019 at 21:19:20 UTC, Walter Bright wrote:
 On 4/7/2019 10:14 AM, Yuxuan Shui wrote:
 this proposal seems to mandate the inclusion of parameter 
 names in mangled name of functions.
Nope.
OK, I probably misunderstood, but what happens in the following case? void fun(int a, int b) {...} void fun(int c, int d) {...} fun(c:1, d:1); Is it ambiguous? Or does it invoke the second function? If the latter, then you have to include the parameter names in mangled name.
That wouldn't work because the compiler would reject your function definitions when you attempt to call either of them because they're ambiguous. Just like it is today. Basically you could look at them just being: void fun(int,int); void fun(int,int); When you call a function like: void fun(int a, int b); ... fun(a: 1, b: 2); the compiler would really just reorder the passed values to match the parameters (If they can be specified in any order, if not then it will just them as it is. Which means: fun(a: 1, b: 2); becomes: fun(1, 2); and by then it should be clear why it wouldn't be allowed nor would work at all.
Yes, what you said _could_ be the case. But it's not immediately clear from Walter's proposal, that's why I would prefer a direct answer from him. Quoting from Walter's proposal:
 I.e. function resolution is done by constructing an argument 
 list separately for each function before testing it for 
 matching. Of course, if the parameter name(s) don't match, the 
 function doesn't match.
From that, it sounds like fun(c:1,d:1) shouldn't match fun(int a, int b). That's why I asked that question. The interpretation of his proposal suggested by you (i.e. this call is ambiguous) is obviously a possible one, but not necessarily what Walter intended.
Apr 08
parent reply bauss <jj_1337 live.dk> writes:
On Monday, 8 April 2019 at 16:33:36 UTC, Yuxuan Shui wrote:
 On Monday, 8 April 2019 at 13:31:48 UTC, bauss wrote:
 On Monday, 8 April 2019 at 10:10:14 UTC, Yuxuan Shui wrote:
 On Sunday, 7 April 2019 at 21:19:20 UTC, Walter Bright wrote:
 On 4/7/2019 10:14 AM, Yuxuan Shui wrote:
 this proposal seems to mandate the inclusion of parameter 
 names in mangled name of functions.
Nope.
OK, I probably misunderstood, but what happens in the following case? void fun(int a, int b) {...} void fun(int c, int d) {...} fun(c:1, d:1); Is it ambiguous? Or does it invoke the second function? If the latter, then you have to include the parameter names in mangled name.
That wouldn't work because the compiler would reject your function definitions when you attempt to call either of them because they're ambiguous. Just like it is today. Basically you could look at them just being: void fun(int,int); void fun(int,int); When you call a function like: void fun(int a, int b); ... fun(a: 1, b: 2); the compiler would really just reorder the passed values to match the parameters (If they can be specified in any order, if not then it will just them as it is. Which means: fun(a: 1, b: 2); becomes: fun(1, 2); and by then it should be clear why it wouldn't be allowed nor would work at all.
Yes, what you said _could_ be the case. But it's not immediately clear from Walter's proposal, that's why I would prefer a direct answer from him. Quoting from Walter's proposal:
 I.e. function resolution is done by constructing an argument 
 list separately for each function before testing it for 
 matching. Of course, if the parameter name(s) don't match, the 
 function doesn't match.
From that, it sounds like fun(c:1,d:1) shouldn't match fun(int a, int b). That's why I asked that question. The interpretation of his proposal suggested by you (i.e. this call is ambiguous) is obviously a possible one, but not necessarily what Walter intended.
No it wouldn't match that BUT the compiler would reject that regardless of named parameters being implemented or not. See: void fun(int a, int b) {...} void fun(int c, int d) {...} Which fun am I calling here? fun(1,2); The same issue would exist with named parameters even with Walter's proposal and there would be no way to resolve it unless the mangling of the function contained the parameter names which Walter said they wouldn't. And in that case it doesn't matter really because it's not a situation that would ever happen.
Apr 08
parent reply Daniel N <no public.email> writes:
On Monday, 8 April 2019 at 23:09:31 UTC, bauss wrote:
 On Monday, 8 April 2019 at 16:33:36 UTC, Yuxuan Shui wrote:
 The interpretation of his proposal suggested by you (i.e. this 
 call is ambiguous) is obviously a possible one, but not 
 necessarily what Walter intended.
And in that case it doesn't matter really because it's not a situation that would ever happen.
Even if 'D' somehow defined that this is valid D code: void x(int p1) {} void x(int p2) {} Some linkers would refuse to link it (including our own OPTLINK and the MS linker), since D has to support a great number of different linkers, we cannot mandate that all linkers in the world need to have a special force flag to override and link anyway just to be compatible with the above construct. For that reason I don't think Walters comment is open for interpretation, the above program is ill-formed. Even if, for compilation speed optimization reasons, the compiler might not be required to issue a diagnostic, it still doesn't change the fact that the program is ill-formed, another conforming D compiler should be allowed to reject that code.
Apr 09
next sibling parent bauss <jj_1337 live.dk> writes:
On Tuesday, 9 April 2019 at 07:21:33 UTC, Daniel N wrote:
 On Monday, 8 April 2019 at 23:09:31 UTC, bauss wrote:
 On Monday, 8 April 2019 at 16:33:36 UTC, Yuxuan Shui wrote:
 The interpretation of his proposal suggested by you (i.e. 
 this call is ambiguous) is obviously a possible one, but not 
 necessarily what Walter intended.
And in that case it doesn't matter really because it's not a situation that would ever happen.
Even if 'D' somehow defined that this is valid D code: void x(int p1) {} void x(int p2) {} Some linkers would refuse to link it (including our own OPTLINK and the MS linker), since D has to support a great number of different linkers, we cannot mandate that all linkers in the world need to have a special force flag to override and link anyway just to be compatible with the above construct. For that reason I don't think Walters comment is open for interpretation, the above program is ill-formed. Even if, for compilation speed optimization reasons, the compiler might not be required to issue a diagnostic, it still doesn't change the fact that the program is ill-formed, another conforming D compiler should be allowed to reject that code.
It's not valid D code when you try to call them, which is why it won't matter.
Apr 09
prev sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 09/04/2019 7:21 PM, Daniel N wrote:
 On Monday, 8 April 2019 at 23:09:31 UTC, bauss wrote:
 On Monday, 8 April 2019 at 16:33:36 UTC, Yuxuan Shui wrote:
 The interpretation of his proposal suggested by you (i.e. this call 
 is ambiguous) is obviously a possible one, but not necessarily what 
 Walter intended.
And in that case it doesn't matter really because it's not a situation that would ever happen.
Even if 'D' somehow defined that this is valid D code: void x(int p1) {} void x(int p2) {} Some linkers would refuse to link it (including our own OPTLINK and the MS linker), since D has to support a great number of different linkers, we cannot mandate that all linkers in the world need to have a special force flag to override and link anyway just to be compatible with the above construct. For that reason I don't think Walters comment is open for interpretation, the above program is ill-formed. Even if, for compilation speed optimization reasons, the compiler might not be required to issue a diagnostic, it still doesn't change the fact that the program is ill-formed, another conforming D compiler should be allowed to reject that code.
In DIP 1020 I did not want or allowed named parameters to affect name mangling or lookup. Its a very simple solution, but it solves so many problems.
Apr 09