June 25, 2008
Bill Baxter wrote:
> Jarrett Billingsley wrote:
>> "Bill Baxter" <dnewsgroup@billbaxter.com> wrote in message news:g3s45g$1ork$1@digitalmars.com...
>>>> Tricky, but I'm sure that some (reasonable) constraints could be put on this type of function to make it easier to disambiguate.
>>> One thing that's lacking is that you wouldn't be able to tell which named parameters were set vs which not set.
>> Ooh, yeah.
>>>> Failing using structs as named parameters, there's certainly nothing stopping the compiler from allowing named parameters with functions as they are now.  They have the names right there :P
>>> Except 36 years of experience with C and C++ that makes people expect that the names of formal parameters don't matter.  I think the only way to make such a big change palatable at this point is to require some special syntax to use it.
>> Funny, I don't feel the same way, probably because I've used D more than I have C or C++ ;)
> Ok, but it would have impact on a backlog of 10 years' worth of D code too.  I agree it would be cool to have, but I also agree with Walter that switching D's default scheme to named parameters at this point would incur too much cost for too little benefit.
> But when whoever sits down to start writing D++ or E, I hope he gives named parameters some serious thought.  That and putting the type after the variable instead of before.
> --bb

For what it's worth, if you really want you can fake named parameters with templates and typedefs.

typedef int _Foo;
_Foo Foo(int i) { return cast(_Foo) i; }

void test(T...)(T t) {
  // test for presence of a _Foo in t

void main() { test(Foo=5); }
Next ›   Last »
1 2