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 2019
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
Mar 31 2019
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 



AFAIK, languages don't have dedicated named parameters.
Apr 01 2019
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



 
 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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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. Münch
http://www.saphirion.com
smarter | better | faster
Mar 31 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 


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 2019
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 


 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 2019
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

 
 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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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!












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.



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.



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.



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.


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.



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 2019
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 2019
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 2019
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 2019
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
That solves function arguments, what is your proposal for templates?
Apr 07 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019