Jim wrote:
Jonathan M Davis Wrote:
On Tuesday, March 01, 2011 11:22:17 Bekenn wrote:
On 2/28/11 1:38 PM, Don wrote:
1. It makes parameter names part of the API.
I wrote earlier that this would probably be the first time parameter
names "leaked" into user code, but I was wrong. Jacob Carlborg has
pointed out his library implementation of this feature:
http://dsource.org/projects/orange/browser/orange/util/Reflection.d#L135
If you look through his implementation, you'll see that it uses the
.stringof property to extract parameter names from the function
definition. In essence, parameter names are /already/ part of the API,
because code can be written that depends on them. And the fact that a
library implementation exists specifically to facilitate the use of
named arguments implies that code already /has/ been written that
depends on parameter names.
Like it or not, parameter names are already part of the API. Adding
named arguments as a language feature doesn't change that.
You're talking about a third party library that's trying to hack in named
arguments, not the language nor the standard library.
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.
- Jonathan M Davis
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.
The library writer has no choice.
Templates function implementation must be included in the .di file. This
exposes the parameter names.
The proposal introduces additional coupling between library code and
user code, which is useless in the majority of cases.
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.
