www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Named parameters

reply "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 
languages like C#.
Jul 24 2015
next sibling parent reply "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 
 languages like C#.
Here's a thread that dealt with this question: http://forum.dlang.org/post/m1g3kb$njo$1 digitalmars.com
Jul 24 2015
parent reply "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 
 languages like C#.
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.
Jul 24 2015
parent reply 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.
Jul 24 2015
next sibling parent 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.
Jul 25 2015
prev sibling parent reply 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
Jul 25 2015
next sibling parent reply "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
Jul 25 2015
parent reply 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
Jul 25 2015
parent reply 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.
Jul 25 2015
parent reply "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
Jul 25 2015
parent 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.=
Jul 28 2015
prev sibling next sibling parent reply "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!
Jul 25 2015
parent 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
Jul 25 2015
prev sibling parent reply 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
Jul 25 2015
next sibling parent reply "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.
Jul 25 2015
next sibling parent 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
Jul 25 2015
prev sibling parent reply 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.
Jul 25 2015
parent 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));
Jul 25 2015
prev sibling parent 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
Jul 25 2015
prev sibling next sibling parent 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
 like C#.
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
Jul 24 2015
prev sibling next sibling parent reply "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 
 languages like C#.
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
Jul 24 2015
parent reply "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 
 languages like C#.
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
Funny, they work beautifully in C#. https://msdn.microsoft.com/en-us/library/dd264739.aspx
Jul 24 2015
next sibling parent reply "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 
 in languages like C#.
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
Funny, they work beautifully in C#. https://msdn.microsoft.com/en-us/library/dd264739.aspx
Well, I don't know how C# dealt with mixing function overloading 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
Jul 24 2015
parent reply 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?
 There are extremely handy and work beautifully in languages like C#.
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
Funny, they work beautifully in C#. https://msdn.microsoft.com/en-us/library/dd264739.aspx
Well, I don't know how C# dealt with mixing function 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 :-)
Jul 24 2015
parent "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:
 Funny, they work beautifully in C#.

 https://msdn.microsoft.com/en-us/library/dd264739.aspx
Well, I don't know how C# dealt with mixing function 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
Jul 24 2015
prev sibling parent "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 
 in languages like C#.
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
Funny, they work beautifully in C#. https://msdn.microsoft.com/en-us/library/dd264739.aspx
The example presented in there would benefit from extra typing rather that named argument. D provide this, but C# doesn't as far as I know.
Jul 24 2015
prev sibling next sibling parent reply "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 
 languages like C#.
1. This isn't C# 2. I'm sure a template solution would work just fine. I've seen many on these forums.
Jul 25 2015
parent reply "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
Jul 25 2015
next sibling parent "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
Jul 25 2015
prev sibling parent 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
Jul 25 2015
prev sibling parent 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?
  There are extremely handy and work beautifully in languages like C#.
'cause core devs doesn't see much added value in named args. this=20 question was talked to death already. alas.=
Jul 25 2015