www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - named parameters to functions

reply Zola <nospam please.com> writes:
Hi,

I'm amazed by some things D does have,
Except I'm puzzled by this one one gaping hole in D.

It's something I've been pissed off about C++ for 10 years now:
Named parameters to functions.

window* w = new_window("alert box", movable=false);

We can almost do this in C++ today with boost.parameter and I hate it so much
that I refuse to use it, because the only way to do so is by polluting your
namespace.

I'm really surprised to see that D doesn't have this super important feature.
It redefines and simplifies a whole world of class design.. for user interfaces
especially.

If D included this, I think it would be the tipping point to really getting me
into D, and making a serious library for it.

Please.

- Z
Oct 11 2007
next sibling parent Zola <nospam please.com> writes:
I wouldn't even mind if it had a syntax like:

window* w = new_window(("alert box", movable=false));

- Z
Oct 11 2007
prev sibling next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Zola,


 Hi,
 
 I'm amazed by some things D does have,
 Except I'm puzzled by this one one gaping hole in D.
 It's something I've been pissed off about C++ for 10 years now: Named
 parameters to functions.
 
 window* w = new_window("alert box", movable=false);
 
 We can almost do this in C++ today with boost.parameter and I hate it
 so much that I refuse to use it, because the only way to do so is by
 polluting your namespace.
 
 I'm really surprised to see that D doesn't have this super important
 feature. It redefines and simplifies a whole world of class design..
 for user interfaces especially.
 
 If D included this, I think it would be the tipping point to really
 getting me into D, and making a serious library for it.
 
 Please.
 
 - Z
 


It's have been proposed and favorably received. It's now on the list of things 
to do at some point in the not to distant future.

For now you can sort of fake it with struct literals.
Oct 11 2007
next sibling parent renoX <renosky free.fr> writes:
BCS a écrit :

 Reply to Zola,
 

 Hi,

 I'm amazed by some things D does have,
 Except I'm puzzled by this one one gaping hole in D.
 It's something I've been pissed off about C++ for 10 years now: Named
 parameters to functions.

 window* w = new_window("alert box", movable=false);

 We can almost do this in C++ today with boost.parameter and I hate it
 so much that I refuse to use it, because the only way to do so is by
 polluting your namespace.

 I'm really surprised to see that D doesn't have this super important
 feature. It redefines and simplifies a whole world of class design..
 for user interfaces especially.

 If D included this, I think it would be the tipping point to really
 getting me into D, and making a serious library for it.

 Please.

 - Z


 
 It's have been proposed and favorably received. It's now on the list of 
 things to do at some point in the not to distant future.


That's a good news, I do agree with the original poster that it'll make 
code much more readable.

renoX

 
 For now you can sort of fake it with struct literals.
Oct 11 2007
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
BCS wrote:

 Reply to Zola,
 

 Hi,

 I'm amazed by some things D does have,
 Except I'm puzzled by this one one gaping hole in D.
 It's something I've been pissed off about C++ for 10 years now: Named
 parameters to functions.

 window* w = new_window("alert box", movable=false);

 We can almost do this in C++ today with boost.parameter and I hate it
 so much that I refuse to use it, because the only way to do so is by
 polluting your namespace.

 I'm really surprised to see that D doesn't have this super important
 feature. It redefines and simplifies a whole world of class design..
 for user interfaces especially.

 If D included this, I think it would be the tipping point to really
 getting me into D, and making a serious library for it.

 Please.

 - Z


 
 It's have been proposed and favorably received. It's now on the list of 
 things to do at some point in the not to distant future.


Favorably received by whom?  I recall lengthy discussions -- I started 
one of them with a post remarkably like Zola's as one of my first posts 
to the D newsgroup -- but I don't recall any favorable reception except 
by other D users.   And the fact that it didn't make it into the 
WalterAndrei.pdf makes me think that if D gets it at all it will be 
after all that stuff, so methinks it will be "distant future" at best.


 For now you can sort of fake it with struct literals.


Not really.  Struct literals 
(http://www.digitalmars.com/d/1.0/struct.html#StructLiteral) don't give 
you pick-and-choose initialization.  You can't just override the default 
value of the 5th item, for instance.  So in that respect they work just 
like regular function parameter defaults.

Static struct initializers, on the other hand, have the right look, 
x={name:"fred", title:"director"}, but since they only work with 
constants they're not much practical use either.

So you're left with creating a struct explicitly and passing it.

func_args x;  x.name = "fred"; x.title="director";
func(x);  // for func(func_args a);
or
func(x.tupleof); // for func that takes list of args that matches with 
func_args.

Either way it's more trouble than it's worth.

Were you thinking of something else?

--bb
Oct 11 2007
parent reply BCS <ao pathlink.com> writes:
Reply to Bill,


 BCS wrote:
 

 It's have been proposed and favorably received. It's now on the list
 of things to do at some point in the not to distant future.
 


 Favorably received by whom?  I recall lengthy discussions -- I started
 one of them with a post remarkably like Zola's as one of my first
 posts to the D newsgroup -- but I don't recall any favorable reception
 except by other D users. 


Who else matters? As I recall Walter didn't say no.


 And the fact that it didn't make it into
 the WalterAndrei.pdf makes me think that if D gets it at all it will
 be after all that stuff, so methinks it will be "distant future" at
 best.
 


I was thinking "somewhere between 6 months and D3.0"



 For now you can sort of fake it with struct literals.
 


 Not really.  Struct literals
 (http://www.digitalmars.com/d/1.0/struct.html#StructLiteral) don't
 give you pick-and-choose initialization.


[...]

 
 Static struct initializers, on the other hand, have the right look,
 x={name:"fred", title:"director"}, but since they only work with
 constants they're not much practical use either.
 


[...]

 Were you thinking of something else?


<grumble/> 

I though that the {...} form would handle non const. Any Idea why it doesn't?


 
 --bb
Oct 11 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
BCS wrote:

 Reply to Bill,
 

 BCS wrote:


 It's have been proposed and favorably received. It's now on the list
 of things to do at some point in the not to distant future.


 Favorably received by whom?  I recall lengthy discussions -- I started
 one of them with a post remarkably like Zola's as one of my first
 posts to the D newsgroup -- but I don't recall any favorable reception
 except by other D users. 


 
 Who else matters? As I recall Walter didn't say no.


Positive community feedback only matters if it's *overwhelmingly* 
positive community feedback.  Just my observation.  And Walter hasn't 
said no to a lot of things he doesn't have any intention of adding to D. 
  The only useful indicator that he likes an idea is if he says "yes".


 And the fact that it didn't make it into
 the WalterAndrei.pdf makes me think that if D gets it at all it will
 be after all that stuff, so methinks it will be "distant future" at
 best.


 
 I was thinking "somewhere between 6 months and D3.0"
 
 

 For now you can sort of fake it with struct literals.


 Not really.  Struct literals
 (http://www.digitalmars.com/d/1.0/struct.html#StructLiteral) don't
 give you pick-and-choose initialization.


 [...]

 Static struct initializers, on the other hand, have the right look,
 x={name:"fred", title:"director"}, but since they only work with
 constants they're not much practical use either.


 [...]

 Were you thinking of something else?


 
 <grumble/>
 I though that the {...} form would handle non const. Any Idea why it 
 doesn't?


No idea.  Not even C is that limited.  I'm pretty sure {..} struct 
initializers work for any initialization.  And with C99 you can do 
keyword initializations too (using the syntax 
x={.name="walter",.title="BDFL"} ).

--bb
Oct 11 2007
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Zola wrote:

 Hi,
 
 I'm amazed by some things D does have,
 Except I'm puzzled by this one one gaping hole in D.
 
 It's something I've been pissed off about C++ for 10 years now:
 Named parameters to functions.
 
 window* w = new_window("alert box", movable=false);



My suspicion is that this would make name lookup really horrible.

What does this code do?
--
bool movable;
window* w = new_window("alert box", movable=false);
--



 
 We can almost do this in C++ today with boost.parameter and I hate it so much
that I refuse to use it, because the only way to do so is by polluting your
namespace.
 
 I'm really surprised to see that D doesn't have this super important feature.
 It redefines and simplifies a whole world of class design.. for user
interfaces especially.
 
 If D included this, I think it would be the tipping point to really getting me
into D, and making a serious library for it.
 
 Please.
 
 - Z
Oct 12 2007
parent reply David Brown <dlang davidb.org> writes:
On Fri, Oct 12, 2007 at 04:39:25PM +0200, Don Clugston wrote:

 Zola wrote:

 Hi,
 I'm amazed by some things D does have,
 Except I'm puzzled by this one one gaping hole in D.
 It's something I've been pissed off about C++ for 10 years now:
 Named parameters to functions.
 window* w = new_window("alert box", movable=false);



 My suspicion is that this would make name lookup really horrible.

 What does this code do?
 --
 bool movable;
 window* w = new_window("alert box", movable=false);


It would be better to implement using syntax that doesn't conflict with
other parts of the grammar.  Perhaps:

   window* w = new_window ("alert box", movable: false);

Dave
Oct 12 2007
parent reply novice2 <sorry noem.ail> writes:
 It would be better to implement using syntax that doesn't conflict with
 other parts of the grammar.  Perhaps:
 
    window* w = new_window ("alert box", movable: false);
 


or using other language expirence, e.g. oracle pl/sql:
1 - mixing normal and named params prohibited
2 - use special token between param's name an dvalue (pl/sql uses name=>value )
Oct 12 2007
parent David Brown <dlang davidb.org> writes:
On Fri, Oct 12, 2007 at 11:42:07AM -0400, novice2 wrote:

 It would be better to implement using syntax that doesn't conflict with
 other parts of the grammar.  Perhaps:
 
    window* w = new_window ("alert box", movable: false);
 


or using other language expirence, e.g. oracle pl/sql:
1 - mixing normal and named params prohibited


Common is to allow positional parameters first, followed by unnamed
parameters.  This is how most languages do it, including python (sort of),
Ada, ocaml, and probably others.  The basic rule is that once you have a
named parameter, none following it can be positional.


2 - use special token between param's name an dvalue (pl/sql uses name=>value )


The colon is a special token in this case, since it isn't possible in the
existing grammar at this position.  Using an entirely new token might help
make better error messages.

Dave
Oct 12 2007
prev sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
Zola schrieb:

 Hi,
 
 I'm amazed by some things D does have,
 Except I'm puzzled by this one one gaping hole in D.
 
 It's something I've been pissed off about C++ for 10 years now:
 Named parameters to functions.
 
 window* w = new_window("alert box", movable=false);
 
 We can almost do this in C++ today with boost.parameter and I hate it so much
that I refuse to use it, because the only way to do so is by polluting your
namespace.
 
 I'm really surprised to see that D doesn't have this super important feature.
 It redefines and simplifies a whole world of class design.. for user
interfaces especially.
 
 If D included this, I think it would be the tipping point to really getting me
into D, and making a serious library for it.
 
 Please.
 
 - Z


I really second this feature request.

I often deal with generating a framework api from a database or such. So
often the count of parameter can be high. I would like to have named
parameters, so i could copy an example call, an fill in like a form.

doTheAction(
	countOfBananas    => 2,
	errorOnBadQuality => true
);

This makes the code even more readable.

Sure i could do that with comments, but the api might be enhanced or
changed. With named arguments, the compiler can help to show the places,
where a correction is neccessary.

Named arguments are always useful, if the count and sequence of
arguments is not obvious.
For example VHDL/Verilog are using named arguments a lot.

Since D is a multi paradigm language, not everything is OOP and not
every method has less than 4 args.

In my case, where I use a generated API, this would allow better
readability and faster development.

Frank
Dec 15 2007
parent "Peter C. Chapin" <pchapin sover.net> writes:
Frank Benoit wrote:


 Named arguments are always useful, if the count and sequence of
 arguments is not obvious.
 For example VHDL/Verilog are using named arguments a lot.


Ada also has "named parameter association" (as the Ada community calls
it). It is, indeed, a nice feature.

Peter
Dec 15 2007