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.
 

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.
 

(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.

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.

(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
next sibling 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 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
prev sibling 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