I find this an interesting discussion.  Coming from writing alot of code in language that makes extensive and<div>highly effective use of named arguments (R), I can say that optional named arguments <div>(as in Lisp, and descendants like Python and R) do have big software engineering benefits, </div>
<div>but also come with a substantial costs in terms of complexity of the function call sequence.</div><div><br></div><div>That is, named arguments can be expensive in a typical interpreted implementation</div><div>(probably one reason why R and Python are much slower to execute than the other</div>
<div>interpreted languages), presumably because each function call has to invoke hash </div><div>table lookups to determine the canonical formal position of each actual argument, and deal with variadic</div><div>cases, to rearrange the order of the arguments to match expectations of the callee.</div>
<div><br></div><div>Someone familiar with lisp compilers could probably tell you if the heavy speed tax is intrinsic</div><div>or just the price of interpretation. </div><div><br></div><div>It would indeed be an interesting challenge to see if the compile-time metaprogramming</div>
<div>features of D would allow one to include named arguments in an opt-in fashion without speed reduction.</div><div><br></div><div>Jason</div><div><div><br><div class="gmail_quote">On Wed, Mar 2, 2011 at 6:16 AM, Don <span dir="ltr"><<a href="mailto:nospam@nospam.com">nospam@nospam.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div></div><div class="h5">Jim wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Jonathan M Davis Wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tuesday, March 01, 2011 11:22:17 Bekenn wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2/28/11 1:38 PM, Don wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
1. It makes parameter names part of the API.<br>
</blockquote>
I wrote earlier that this would probably be the first time parameter<br>
names "leaked" into user code, but I was wrong.  Jacob Carlborg has<br>
pointed out his library implementation of this feature:<br>
<br>
<a href="http://dsource.org/projects/orange/browser/orange/util/Reflection.d#L135" target="_blank">http://dsource.org/projects/orange/browser/orange/util/Reflection.d#L135</a><br>
<br>
If you look through his implementation, you'll see that it uses the<br>
.stringof property to extract parameter names from the function<br>
definition.  In essence, parameter names are /already/ part of the API,<br>
because code can be written that depends on them.  And the fact that a<br>
library implementation exists specifically to facilitate the use of<br>
named arguments implies that code already /has/ been written that<br>
depends on parameter names.<br>
<br>
Like it or not, parameter names are already part of the API.  Adding<br>
named arguments as a language feature doesn't change that.<br>
</blockquote>
You're talking about a third party library that's trying to hack in named arguments, not the language nor the standard library.<br>
<br>
The parameter names of a function are _not_ currently part of its signature. You could have a .di file without any parameter names or with totally different parameter names than the original .d file and it would have _zero_ effect on anything calling those functions. The function signature does _not_ include the name of its parameters - just their types. Adding named arguments would change that.<br>

<br>
- Jonathan M Davis<br>
</blockquote>
<br>
<br>
Neither are aliases signatures but they can still be imported. If the library writer choose to expose argument names in the .di file then I'd say they are part of the API.<br>
</blockquote>
<br></div></div>
The library writer has no choice.<br>
Templates function implementation must be included in the .di file. This exposes the parameter names.<br>
<br>
The proposal introduces additional coupling between library code and user code, which is useless in the majority of cases.<br>
<br>
I can see the value in an opt-in annotation (*not* opt-out) for those problem domains where large numbers of function parameters are normal. But I would strongly oppose it in general.<br>
<br>
</blockquote></div><br><br>
</div></div></div>