• Shammah Chancellor (3/3) Jul 24 2015 Since D has optional arguments -- why don't we support named
• Chris (3/6) Jul 24 2015 Here's a thread that dealt with this question:
• tcak (11/18) Jul 24 2015 Okay, understood that wrong ordered named parameters might create
• Walter Bright (2/3) Jul 24 2015 The question is what problem does it solve.
• Johannes Pfau (21/25) Jul 25 2015 At least:
• Jacob Carlborg (11/12) Jul 25 2015 For one thing, it avoids the ugly hack which is the Flag template and
• Jonathan M Davis (7/17) Jul 25 2015 If Andrei weren't insisting that we use that idiom everywhere in
• Andrei Alexandrescu (3/25) Jul 25 2015 Honest I didn't insist, and am a bit surprised that it did catch up. --
• Walter Bright (4/11) Jul 25 2015 Well, somebody was insisting and my PR's wouldn't get pulled without con...
• Jonathan M Davis (6/23) Jul 25 2015 Several of those with commit access seem to have taken a liking
• ketmar (17/25) Jul 28 2015 semi-OT: as D has no named args, and i want to stay compatible, i adopte...
• Gary Willoughby (5/15) Jul 25 2015 When showing code don't purposefully make it verbose to
• Jacob Carlborg (5/9) Jul 25 2015 I disagree, Flag/Yes/No is a gigantic ugly hack.
• Andrei Alexandrescu (4/11) Jul 25 2015 Replace the second with:
• Martin Nowak (13/19) Jul 25 2015 The idiom goes like this.
• Andrei Alexandrescu (2/13) Jul 25 2015 I think dispensing with the alias is significantly better. -- Andrei
• Johannes Pfau (14/38) Jul 25 2015 Named boolean flags are only one very common special case though. That
• Daniel Kozak via Digitalmars-d (5/14) Jul 25 2015 auto w = Window(Position(0,0), Dimension(100, 200)); // this is what I p...
• Jacob Carlborg (5/7) Jul 25 2015 As I answered in the other post I just copied the example from the
• Jacob Carlborg (18/21) Jul 24 2015 I think it would really good to have in D, especially since bool
• Jonathan M Davis (7/10) Jul 24 2015 We've argued about this several times in the past. We're not
• Shammah Chancellor (3/14) Jul 24 2015 Funny, they work beautifully in C#.
• Jonathan M Davis (18/34) Jul 24 2015 Well, I don't know how C# dealt with mixing function overloading
• Walter Bright (21/39) Jul 24 2015 Here's what it says:
• Jonathan M Davis (9/42) Jul 24 2015 Yeah. That sounds pretty ugly. And in D, we already tend to lean
• deadalnix (4/20) Jul 24 2015 The example presented in there would benefit from extra typing
• Gary Willoughby (4/7) Jul 25 2015 1. This isn't C#
• Gary Willoughby (3/5) Jul 25 2015 Here's one:
• Gary Willoughby (3/9) Jul 25 2015 Some more:
• Jacob Carlborg (5/7) Jul 25 2015 That's ugly and it doesn't work fine, at least not that implementation.
• ketmar (3/5) Jul 25 2015 'cause core devs doesn't see much added value in named args. this=20

"Shammah Chancellor" <shammah.chancellor gmail.com> writes:

Since D has optional arguments -- why don't we support named 
parameters?  There are extremely handy and work beautifully in 

"Chris" <wendlec tcd.ie> writes:

On Friday, 24 July 2015 at 14:15:11 UTC, Shammah Chancellor wrote:
 Since D has optional arguments -- why don't we support named 
 parameters?  There are extremely handy and work beautifully in 


Here's a thread that dealt with this question:

http://forum.dlang.org/post/m1g3kb$njo$1 digitalmars.com

"tcak" <1ltkrs+3wyh1ow7kzn1k sharklasers.com> writes:

On Friday, 24 July 2015 at 14:34:12 UTC, Chris wrote:
 On Friday, 24 July 2015 at 14:15:11 UTC, Shammah Chancellor 
 wrote:
 Since D has optional arguments -- why don't we support named 
 parameters?  There are extremely handy and work beautifully in 


 Here's a thread that dealt with this question:

 http://forum.dlang.org/post/m1g3kb$njo$1 digitalmars.com


Okay, understood that wrong ordered named parameters might create 
overloading problem, but why skipping parameters is not allowed, 
I don't get that one though.

[code]
void test(int a=5, int b){
}

test( , 7 );
[/code]

Programmer should still be forced to provide all parameters in 
correct order. How would this create a problem I can't see.

Walter Bright <newshound2 digitalmars.com> writes:

On 7/24/2015 10:15 AM, tcak wrote:
 How would this create a problem I can't see.

The question is what problem does it solve.

Johannes Pfau <nospam example.com> writes:

Am Fri, 24 Jul 2015 14:04:17 -0700
schrieb Walter Bright <newshound2 digitalmars.com>:

 On 7/24/2015 10:15 AM, tcak wrote:
 How would this create a problem I can't see.

 
 The question is what problem does it solve.

At least:
1 Better readable code with literal parameters
  auto x = window.addNewControl("Title", 20, 50, 100, 50, true);
  There are some domains which would benefit a lot from this (every
  OpenGL function call, most graphics/image libraries)

2 If you have many parameters with default values, you can keep default
  values for all other parameters and overwrite only one. This can
  sometimes be done with overloads, but what if you've got parameters
  of the same type:
  void foo(bool a = function1(x, y), bool b = function2(x, y), bool c =
      function1(x, y))
  foo(function1(x, y), function2(x, y), false); => foo(c = false)

3 One thing that's sometimes annoying in D is that it's not possible to
  have normal arguments after a variadic argument. Named parameters
  could solve that:
  void foo(A, T... args, B) => foo!(int, int, bool, B = bool)


Note that there are languages which allow named parameters but do not
allow parameter reordering. This still allows 1 and 3 but the
implementation is simpler.

Jacob Carlborg <doob me.com> writes:

On 2015-07-24 23:04, Walter Bright wrote:

 The question is what problem does it solve.

For one thing, it avoids the ugly hack which is the Flag template and 
Yes/No structs.

With Flag:

string getLine(Flag!"keepTerminator" keepTerminator);
getLine(Flag!"keepTerminator".yes);

With named parameters:

string getLine(bool keepTerminator);
getLine(keepTerminator: true);

-- 
/Jacob Carlborg

"Jonathan M Davis" <jmdavisProg gmx.com> writes:

On Saturday, 25 July 2015 at 09:41:19 UTC, Jacob Carlborg wrote:
 On 2015-07-24 23:04, Walter Bright wrote:

 The question is what problem does it solve.

 For one thing, it avoids the ugly hack which is the Flag 
 template and Yes/No structs.

 With Flag:

 string getLine(Flag!"keepTerminator" keepTerminator);
 getLine(Flag!"keepTerminator".yes);

 With named parameters:

 string getLine(bool keepTerminator);
 getLine(keepTerminator: true);

If Andrei weren't insisting that we use that idiom everywhere in 
Phobos, I'd honestly just be using bools and be done with it. It 
adds some value, but I seriously question that it's worth the 
extra verbosity. But regardless, I'd hate to see named arguments 
get added to the language just to clean that mess up.

- Jonathan M Davis

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 7/25/15 6:32 AM, Jonathan M Davis wrote:
 On Saturday, 25 July 2015 at 09:41:19 UTC, Jacob Carlborg wrote:
 On 2015-07-24 23:04, Walter Bright wrote:

 The question is what problem does it solve.

 For one thing, it avoids the ugly hack which is the Flag template and
 Yes/No structs.

 With Flag:

 string getLine(Flag!"keepTerminator" keepTerminator);
 getLine(Flag!"keepTerminator".yes);

 With named parameters:

 string getLine(bool keepTerminator);
 getLine(keepTerminator: true);

 If Andrei weren't insisting that we use that idiom everywhere in Phobos,
 I'd honestly just be using bools and be done with it. It adds some
 value, but I seriously question that it's worth the extra verbosity. But
 regardless, I'd hate to see named arguments get added to the language
 just to clean that mess up.

Honest I didn't insist, and am a bit surprised that it did catch up. -- 
Andrei

Walter Bright <newshound2 digitalmars.com> writes:

On 7/25/2015 6:54 AM, Andrei Alexandrescu wrote:
 On 7/25/15 6:32 AM, Jonathan M Davis wrote:
 If Andrei weren't insisting that we use that idiom everywhere in Phobos,
 I'd honestly just be using bools and be done with it. It adds some
 value, but I seriously question that it's worth the extra verbosity. But
 regardless, I'd hate to see named arguments get added to the language
 just to clean that mess up.

 Honest I didn't insist, and am a bit surprised that it did catch up. -- Andrei


Well, somebody was insisting and my PR's wouldn't get pulled without converting 
to it. Bluntly, I think insisting on using Flag instead of bool is not worth
the 
bother.

"Jonathan M Davis" <jmdavisProg gmx.com> writes:

On Saturday, 25 July 2015 at 21:14:00 UTC, Walter Bright wrote:
 On 7/25/2015 6:54 AM, Andrei Alexandrescu wrote:
 On 7/25/15 6:32 AM, Jonathan M Davis wrote:
 If Andrei weren't insisting that we use that idiom everywhere 
 in Phobos,
 I'd honestly just be using bools and be done with it. It adds 
 some
 value, but I seriously question that it's worth the extra 
 verbosity. But
 regardless, I'd hate to see named arguments get added to the 
 language
 just to clean that mess up.

 Honest I didn't insist, and am a bit surprised that it did 
 catch up. -- Andrei


 Well, somebody was insisting and my PR's wouldn't get pulled 
 without converting to it. Bluntly, I think insisting on using 
 Flag instead of bool is not worth the bother.

Several of those with commit access seem to have taken a liking 
to it and insist that it's best practice, and I'm not enthused 
about it either. Maybe some of those same devs would like to have 
named arguments as well. I don't know.

- Jonathan M Davis

ketmar <ketmar ketmar.no-ip.org> writes:

On Sat, 25 Jul 2015 23:05:38 +0000, Jonathan M Davis wrote:

 Well, somebody was insisting and my PR's wouldn't get pulled without
 converting to it. Bluntly, I think insisting on using Flag instead of
 bool is not worth the bother.

=20
 Several of those with commit access seem to have taken a liking to it
 and insist that it's best practice, and I'm not enthused about it
 either. Maybe some of those same devs would like to have named arguments
 as well. I don't know.

semi-OT: as D has no named args, and i want to stay compatible, i adopted=20
some another bad style:

  myfunc!"use-x,do-y,skip-z"(...);

i.e. using template with string arg and parse that arg in compile time.=20
while this bloats binary, creating separate functions for each option=20
set, it still allows me to specify user-readable function configs. small=20
example: one of my parsing functions has alot of options (i need 'em to=20
correctly parse both xpath and css), and looks like this:

  lex.nextToken!"spacetokens,comments,no-numbers,extids"();

with named args that can be simple:

  lex.nextToken(spacetokens:true,comments:false<,etc...>);

while this can be done with Flag, of course, what named args can give me=20
is the ability to pass arguments in any order i like -- compiler knows=20
the names and will sort 'em. still nice syntax, no template bloat.

of course, there are other solutions to this, but the only one that=20
doesn't require additional code in lexer is named args one.=

"Gary Willoughby" <dev nomad.so> writes:

On Saturday, 25 July 2015 at 09:41:19 UTC, Jacob Carlborg wrote:
 On 2015-07-24 23:04, Walter Bright wrote:

 The question is what problem does it solve.

 For one thing, it avoids the ugly hack which is the Flag 
 template and Yes/No structs.

 With Flag:

 string getLine(Flag!"keepTerminator" keepTerminator);
 getLine(Flag!"keepTerminator".yes);

 With named parameters:

 string getLine(bool keepTerminator);
 getLine(keepTerminator: true);

When showing code don't purposefully make it verbose to 
strengthen your case. Here is how Flag is usually used:

   getLine(Yes.keepTerminator);

Which is way more readable. Named parameters are not needed!

Jacob Carlborg <doob me.com> writes:

On 2015-07-25 13:02, Gary Willoughby wrote:

 When showing code don't purposefully make it verbose to strengthen your
 case. Here is how Flag is usually used:

I didn't, I just copied it from the documentation. I never used it myself.

    getLine(Yes.keepTerminator);

 Which is way more readable. Named parameters are not needed!

I disagree, Flag/Yes/No is a gigantic ugly hack.

-- 
/Jacob Carlborg

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 7/25/15 5:41 AM, Jacob Carlborg wrote:
 On 2015-07-24 23:04, Walter Bright wrote:

 The question is what problem does it solve.

 For one thing, it avoids the ugly hack which is the Flag template and
 Yes/No structs.

 With Flag:

 string getLine(Flag!"keepTerminator" keepTerminator);
 getLine(Flag!"keepTerminator".yes);

Replace the second with:

getLine(Yes.keepTerminator);


Andrei

"Martin Nowak" <code dawg.eu> writes:

On Saturday, 25 July 2015 at 13:52:09 UTC, Andrei Alexandrescu 
wrote:
 For one thing, it avoids the ugly hack which is the Flag 
 template and
 Yes/No structs.

 With Flag:


The idiom goes like this.

/// Flag to control whether or not to keep line endings
alias KeepTerminator = Flag!"KeepTerminator";
///
string getLine(KeepTerminator KeepTerminator);

usage:

getLine(KeepTerminator.yes);
or
getLine(Yes.keepTerminator);

So named Boolean flags are a solved problem and are a good 
improvement over getLine(true) IMO.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 7/25/15 10:05 AM, Martin Nowak wrote:
 On Saturday, 25 July 2015 at 13:52:09 UTC, Andrei Alexandrescu wrote:
 For one thing, it avoids the ugly hack which is the Flag template and
 Yes/No structs.

 With Flag:


 The idiom goes like this.

 /// Flag to control whether or not to keep line endings
 alias KeepTerminator = Flag!"KeepTerminator";
 ///
 string getLine(KeepTerminator KeepTerminator);

I think dispensing with the alias is significantly better. -- Andrei

Johannes Pfau <nospam example.com> writes:

Am Sat, 25 Jul 2015 14:05:32 +0000
schrieb "Martin Nowak" <code dawg.eu>:

 On Saturday, 25 July 2015 at 13:52:09 UTC, Andrei Alexandrescu 
 wrote:
 For one thing, it avoids the ugly hack which is the Flag 
 template and
 Yes/No structs.

 With Flag:


 
 The idiom goes like this.
 
 /// Flag to control whether or not to keep line endings
 alias KeepTerminator = Flag!"KeepTerminator";
 ///
 string getLine(KeepTerminator KeepTerminator);
 
 usage:
 
 getLine(KeepTerminator.yes);
 or
 getLine(Yes.keepTerminator);
 
 So named Boolean flags are a solved problem and are a good 
 improvement over getLine(true) IMO.

Named boolean flags are only one very common special case though. That
solution doesn't work that well for integers:

auto w = Window(0, 0, 100, 200);
auto w = Window(x = 0, y = 0, width = 100, height = 200);
//auto w = Window(x.0, y.0, width.100, height.200);

You could introduce new types for X,Y, Width, Height:
auto w = Window(X(0), Y(0), Width(100), Height(200));

It doesn't look that bad. But you'll also have to make sure it converts
back to the correct integer types, operator overloading, ... In the end
you always introduce new types for something that is one type with
named parameters. Having extra types is sometimes the correct thing,
sometimes it's not.

Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Sat, 25 Jul 2015 17:16:23 +0200
Johannes Pfau via Digitalmars-d <digitalmars-d puremagic.com> wrote:
 Named boolean flags are only one very common special case though. That
 solution doesn't work that well for integers:
 
 auto w = Window(0, 0, 100, 200);
 auto w = Window(x = 0, y = 0, width = 100, height = 200);
 //auto w = Window(x.0, y.0, width.100, height.200);
 
 You could introduce new types for X,Y, Width, Height:
 auto w = Window(X(0), Y(0), Width(100), Height(200));

auto w = Window(Position(0,0), Dimension(100, 200)); // this is what I prefer

but if someone want to be more explicit:

auto w = Window(Position.x(0).y(0), Dimension.width(100).height(200));

Jacob Carlborg <doob me.com> writes:

On 2015-07-25 15:52, Andrei Alexandrescu wrote:

 Replace the second with:

 getLine(Yes.keepTerminator);

As I answered in the other post I just copied the example from the 
documentation.

-- 
/Jacob Carlborg

Jacob Carlborg <doob me.com> writes:

On 2015-07-24 16:15, Shammah Chancellor wrote:
 Since D has optional arguments -- why don't we support named
 parameters?  There are extremely handy and work beautifully in languages


I think it would really good to have in D, especially since bool 
parameters are basically banned in favor a struct:

// banned
string toString(bool prettyPrint);
toString(false);

// preferred
string toString(PrettyPrint p);
toString(PrettyPrint.no);

// With named parameters
string toString(bool prettyPrint);
toString(prettyPrint: true);

If named parameters don't allow reordering it won't be a problem with 
overloading.

A simple implementation:

https://github.com/jacob-carlborg/dmd/tree/named_parameters

-- 
/Jacob Carlborg

"Jonathan M Davis" <jmdavisProg gmx.com> writes:

On Friday, 24 July 2015 at 14:15:11 UTC, Shammah Chancellor wrote:
 Since D has optional arguments -- why don't we support named 
 parameters?  There are extremely handy and work beautifully in 


We've argued about this several times in the past. We're not 
adding them. They interact badly with overloading (especially if 
you try and add more overloads later), and they make it so that 
the parameter names are part of the API, which means even more 
bikeshedding and arguments about naming.

- Jonathan M Davis

"Shammah Chancellor" <s s.com> writes:

On Friday, 24 July 2015 at 19:45:55 UTC, Jonathan M Davis wrote:
 On Friday, 24 July 2015 at 14:15:11 UTC, Shammah Chancellor 
 wrote:
 Since D has optional arguments -- why don't we support named 
 parameters?  There are extremely handy and work beautifully in 


 We've argued about this several times in the past. We're not 
 adding them. They interact badly with overloading (especially 
 if you try and add more overloads later), and they make it so 
 that the parameter names are part of the API, which means even 
 more bikeshedding and arguments about naming.

 - Jonathan M Davis



https://msdn.microsoft.com/en-us/library/dd264739.aspx

"Jonathan M Davis" <jmdavisProg gmx.com> writes:

On Friday, 24 July 2015 at 19:59:17 UTC, Shammah Chancellor wrote:
 On Friday, 24 July 2015 at 19:45:55 UTC, Jonathan M Davis wrote:
 On Friday, 24 July 2015 at 14:15:11 UTC, Shammah Chancellor 
 wrote:
 Since D has optional arguments -- why don't we support named 
 parameters?  There are extremely handy and work beautifully 


 We've argued about this several times in the past. We're not 
 adding them. They interact badly with overloading (especially 
 if you try and add more overloads later), and they make it so 
 that the parameter names are part of the API, which means even 
 more bikeshedding and arguments about naming.

 - Jonathan M Davis



 https://msdn.microsoft.com/en-us/library/dd264739.aspx


with named arguments (I haven't read the article yet), but there 
_are_ issues with mixing them, and Walter's sure that they 
interact badly enough that he's against adding named arguments to 
D, and if anyone wants them, they'll have to convince him 
otherwise.

But I for one, hope _very_ much that they never end up in either 
D or C++ (which are the two main languages I use). IMHO, they're 
hideous, and if you need them, you have too many function 
arguments/parameters. And I _hate_ the fact that they make it so 
that the function's parameters are part of the API. It just makes 
something else that you have to get right up front and can't 
change later without breaking someone's code.

But for those who really want to have them, they can always 
create them themselves via templates:

http://forum.dlang.org/post/hdxnptcikgojdkmldzrk forum.dlang.org

- Jonathan M Davis

Walter Bright <newshound2 digitalmars.com> writes:

On 7/24/2015 1:11 PM, Jonathan M Davis wrote:
 On Friday, 24 July 2015 at 19:59:17 UTC, Shammah Chancellor wrote:
 On Friday, 24 July 2015 at 19:45:55 UTC, Jonathan M Davis wrote:
 On Friday, 24 July 2015 at 14:15:11 UTC, Shammah Chancellor wrote:
 Since D has optional arguments -- why don't we support named parameters?


 We've argued about this several times in the past. We're not adding them.
 They interact badly with overloading (especially if you try and add more
 overloads later), and they make it so that the parameter names are part of
 the API, which means even more bikeshedding and arguments about naming.

 - Jonathan M Davis



 https://msdn.microsoft.com/en-us/library/dd264739.aspx


 arguments (I haven't read the article yet)

Here's what it says:

-----------------
Use of named and optional arguments affects overload resolution in the
following 
ways:

•A method, indexer, or constructor is a candidate for execution if each of
its 
parameters either is optional or corresponds, by name or by position, to a 
single argument in the calling statement, and that argument can be converted to 
the type of the parameter.


•If more than one candidate is found, overload resolution rules for preferred 
conversions are applied to the arguments that are explicitly specified. Omitted 
arguments for optional parameters are ignored.


•If two candidates are judged to be equally good, preference goes to a
candidate 
that does not have optional parameters for which arguments were omitted in the 
call. This is a consequence of a general preference in overload resolution for 
candidates that have fewer parameters.
--------------------

D already has plenty enough overloading rules, UFCS, overloading templates with 
non-templates, default values, constraints, overriding, 
covariance/contravariance, auto ref, etc., enough to thoroughly confuse
everyone 
already :-)

"Jonathan M Davis" <jmdavisProg gmx.com> writes:

On Friday, 24 July 2015 at 21:11:20 UTC, Walter Bright wrote:
 On 7/24/2015 1:11 PM, Jonathan M Davis wrote:
 On Friday, 24 July 2015 at 19:59:17 UTC, Shammah Chancellor 
 wrote:


 https://msdn.microsoft.com/en-us/library/dd264739.aspx


 overloading with named
 arguments (I haven't read the article yet)

 Here's what it says:

 -----------------
 Use of named and optional arguments affects overload resolution 
 in the following ways:

 •A method, indexer, or constructor is a candidate for execution 
 if each of its parameters either is optional or corresponds, by 
 name or by position, to a single argument in the calling 
 statement, and that argument can be converted to the type of 
 the parameter.


 •If more than one candidate is found, overload resolution rules 
 for preferred conversions are applied to the arguments that are 
 explicitly specified. Omitted arguments for optional parameters 
 are ignored.


 •If two candidates are judged to be equally good, preference 
 goes to a candidate that does not have optional parameters for 
 which arguments were omitted in the call. This is a consequence 
 of a general preference in overload resolution for candidates 
 that have fewer parameters.
 --------------------

 D already has plenty enough overloading rules, UFCS, 
 overloading templates with non-templates, default values, 
 constraints, overriding, covariance/contravariance, auto ref, 
 etc., enough to thoroughly confuse everyone already :-)

Yeah. That sounds pretty ugly. And in D, we already tend to lean 
towards giving an error rather than picking a better option over 
a worse one in order to minimize problems related to overloading. 
We don't need that mess to be even more complicated - especially 
just for syntactic sugar (though I confess, that I do think that 
it's syntactic salt, so I'm obviously a bit biased against it 
anyway).

- Jonathan M Davis

"deadalnix" <deadalnix gmail.com> writes:

On Friday, 24 July 2015 at 19:59:17 UTC, Shammah Chancellor wrote:
 On Friday, 24 July 2015 at 19:45:55 UTC, Jonathan M Davis wrote:
 On Friday, 24 July 2015 at 14:15:11 UTC, Shammah Chancellor 
 wrote:
 Since D has optional arguments -- why don't we support named 
 parameters?  There are extremely handy and work beautifully 


 We've argued about this several times in the past. We're not 
 adding them. They interact badly with overloading (especially 
 if you try and add more overloads later), and they make it so 
 that the parameter names are part of the API, which means even 
 more bikeshedding and arguments about naming.

 - Jonathan M Davis



 https://msdn.microsoft.com/en-us/library/dd264739.aspx

The example presented in there would benefit from extra typing 

as I know.

"Gary Willoughby" <dev nomad.so> writes:

On Friday, 24 July 2015 at 14:15:11 UTC, Shammah Chancellor wrote:
 Since D has optional arguments -- why don't we support named 
 parameters?  There are extremely handy and work beautifully in 



2. I'm sure a template solution would work just fine. I've seen 
many on these forums.

"Gary Willoughby" <dev nomad.so> writes:

On Saturday, 25 July 2015 at 11:11:30 UTC, Gary Willoughby wrote:
 2. I'm sure a template solution would work just fine. I've seen 
 many on these forums.

Here's one:
https://github.com/jacob-carlborg/mambo/blob/master/mambo/util/Reflection.d#L135

"Gary Willoughby" <dev nomad.so> writes:

On Saturday, 25 July 2015 at 11:14:39 UTC, Gary Willoughby wrote:
 On Saturday, 25 July 2015 at 11:11:30 UTC, Gary Willoughby 
 wrote:
 2. I'm sure a template solution would work just fine. I've 
 seen many on these forums.

 Here's one:
 https://github.com/jacob-carlborg/mambo/blob/master/mambo/util/Reflection.d#L135

Some more:
http://forum.dlang.org/thread/wokfqqbexazcguffwiif forum.dlang.org

Jacob Carlborg <doob me.com> writes:

On 2015-07-25 13:14, Gary Willoughby wrote:

 Here's one:
 https://github.com/jacob-carlborg/mambo/blob/master/mambo/util/Reflection.d#L135

That's ugly and it doesn't work fine, at least not that implementation. 
It doesn't handle delegate/function parameters.

-- 
/Jacob Carlborg

ketmar <ketmar ketmar.no-ip.org> writes:

On Fri, 24 Jul 2015 14:15:10 +0000, Shammah Chancellor wrote:

 Since D has optional arguments -- why don't we support named parameters?


'cause core devs doesn't see much added value in named args. this=20
question was talked to death already. alas.=