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 wouldn't even mind if it had a syntax like:

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

- Z

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.

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

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

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
> 

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

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

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

> 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 )