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