• ixid (16/16) Apr 19 2012 I put this here because it's probably a flawed idea. A 'learn'
• ixid (6/6) Apr 19 2012 And while I think about it why not allow the following to make b
• Jacob Carlborg (5/20) Apr 19 2012 Named arguments would probably be better for this.
• Jacob Carlborg (7/31) Apr 19 2012 Which is actually possible to emulate:
• Jakob Ovrum (3/5) Apr 19 2012 Maybe so, but `fun(c = 5);` is not an additive change, while the
• travert phare.normalesup.org (Christophe) (7/15) Apr 20 2012 How about
• Jacob Carlborg (4/17) Apr 20 2012 I don't know. Default arguments would probably take precedence perhaps.
• Jakob Ovrum (5/28) Apr 20 2012 That is exactly the problem though, it can silently change the
• travert phare.normalesup.org (Christophe) (15/19) Apr 23 2012 Hum, an acceptable solution would be to give an error, asking to
• Jacob Carlborg (5/17) Apr 23 2012 Would the following syntax be backwards compatible:
• Jakob Ovrum (4/19) Apr 20 2012 That is what I was talking about. (did you mean to quote the post
• bearophile (8/13) Apr 20 2012 I think that for the programmer's eye it's easy to miss one or

"ixid" <nuaccount gmail.com> writes:

I put this here because it's probably a flawed idea. A 'learn' 
level suggestion.

At present function arguments that you want to default must go at 
the end like so:

int fun(int a = 1, int b = 2, int c = 3)
{
     return a + b + c;
}

fun(4); //Modifies a

where the default fields can only be fields after any argument 
provided. Why not allow something like:

fun( , 4, ); //Modifies b
fun( , , 5); //Modifies c

for when you want to call fun with other fields not being 
default? This would seem more flexible and pretty clear what is 
intended.

"ixid" <nuaccount gmail.com> writes:

And while I think about it why not allow the following to make b 
and c int rather than have to redeclare the type each time?

int fun(int a = 1, b = 2, c = 3)
{
     return a + b + c;
}

Jacob Carlborg <doob me.com> writes:

On 2012-04-19 16:13, ixid wrote:
 I put this here because it's probably a flawed idea. A 'learn' level
 suggestion.

 At present function arguments that you want to default must go at the
 end like so:

 int fun(int a = 1, int b = 2, int c = 3)
 {
 return a + b + c;
 }

 fun(4); //Modifies a

 where the default fields can only be fields after any argument provided.
 Why not allow something like:

 fun( , 4, ); //Modifies b
 fun( , , 5); //Modifies c

 for when you want to call fun with other fields not being default? This
 would seem more flexible and pretty clear what is intended.

Named arguments would probably be better for this.

fun(c = 5);

-- 
/Jacob Carlborg

Jacob Carlborg <doob me.com> writes:

On 2012-04-19 20:34, Jacob Carlborg wrote:
 On 2012-04-19 16:13, ixid wrote:
 I put this here because it's probably a flawed idea. A 'learn' level
 suggestion.

 At present function arguments that you want to default must go at the
 end like so:

 int fun(int a = 1, int b = 2, int c = 3)
 {
 return a + b + c;
 }

 fun(4); //Modifies a

 where the default fields can only be fields after any argument provided.
 Why not allow something like:

 fun( , 4, ); //Modifies b
 fun( , , 5); //Modifies c

 for when you want to call fun with other fields not being default? This
 would seem more flexible and pretty clear what is intended.

 Named arguments would probably be better for this.

 fun(c = 5);

Which is actually possible to emulate:

callWithNamedArguments(fun, "c=5");

See:

https://github.com/jacob-carlborg/orange/blob/master/orange/util/Reflection.d#L135

-- 
/Jacob Carlborg

"Jakob Ovrum" <jakobovrum gmail.com> writes:

On Thursday, 19 April 2012 at 18:34:41 UTC, Jacob Carlborg wrote:
 Named arguments would probably be better for this.

 fun(c = 5);

Maybe so, but `fun(c = 5);` is not an additive change, while the 
OP's suggestion actually is.

travert phare.normalesup.org (Christophe) writes:

"Jakob Ovrum" , dans le message (digitalmars.D.learn:34948), a écrit :
 On Thursday, 19 April 2012 at 18:34:41 UTC, Jacob Carlborg wrote:
 Named arguments would probably be better for this.

 fun(c = 5);

 
 Maybe so, but `fun(c = 5);` is not an additive change, while the 
 OP's suggestion actually is.

How about

int c;
fun(c = 5);

?

-- 
Christophe

Jacob Carlborg <doob me.com> writes:

On 2012-04-20 11:17, Christophe wrote:
 "Jakob Ovrum" , dans le message (digitalmars.D.learn:34948), a écrit :
 On Thursday, 19 April 2012 at 18:34:41 UTC, Jacob Carlborg wrote:
 Named arguments would probably be better for this.

 fun(c = 5);

 Maybe so, but `fun(c = 5);` is not an additive change, while the
 OP's suggestion actually is.

 How about

 int c;
 fun(c = 5);

 ?

I don't know. Default arguments would probably take precedence perhaps.

-- 
/Jacob Carlborg

"Jakob Ovrum" <jakobovrum gmail.com> writes:

On Friday, 20 April 2012 at 11:09:30 UTC, Jacob Carlborg wrote:
 On 2012-04-20 11:17, Christophe wrote:
 "Jakob Ovrum" , dans le message (digitalmars.D.learn:34948), a 
 écrit :
 On Thursday, 19 April 2012 at 18:34:41 UTC, Jacob Carlborg 
 wrote:
 Named arguments would probably be better for this.

 fun(c = 5);

 Maybe so, but `fun(c = 5);` is not an additive change, while 
 the
 OP's suggestion actually is.

 How about

 int c;
 fun(c = 5);

 ?

 I don't know. Default arguments would probably take precedence 
 perhaps.

That is exactly the problem though, it can silently change the 
behaviour of existing code. It is the worst kind of breaking 
change, hence I don't think it will ever be in D in this form, 
much less the current iteration of the language.

travert phare.normalesup.org (Christophe) writes:

"Jakob Ovrum" , dans le message (digitalmars.D.learn:34971), a écrit :
 That is exactly the problem though, it can silently change the 
 behaviour of existing code. It is the worst kind of breaking 
 change, hence I don't think it will ever be in D in this form, 
 much less the current iteration of the language.

Hum, an acceptable solution would be to give an error, asking to 
explicitely asking to fully qualify the name :

void fun(int c = 0) {...}

void main()
{
  int c;
  fun(c=5); // error, ambiguous qualifier "c"
  fun(main.c = 5); // ok
  fun((c=5)); // ok
  fun(fun.c = 5); // ok, but different meaning.
}

But still, raising an arror is not backward compatible.

-- 
Christophe

Jacob Carlborg <doob me.com> writes:

On 2012-04-23 10:05, Christophe wrote:

 Hum, an acceptable solution would be to give an error, asking to
 explicitely asking to fully qualify the name :

 void fun(int c = 0) {...}

 void main()
 {
    int c;
    fun(c=5); // error, ambiguous qualifier "c"
    fun(main.c = 5); // ok
    fun((c=5)); // ok
    fun(fun.c = 5); // ok, but different meaning.
 }

 But still, raising an arror is not backward compatible.

Would the following syntax be backwards compatible:

foo(c: 0)

-- 
/Jacob Carlborg

"Jakob Ovrum" <jakobovrum gmail.com> writes:

On Friday, 20 April 2012 at 09:17:18 UTC, 
travert phare.normalesup.org (Christophe) wrote:
 "Jakob Ovrum" , dans le message (digitalmars.D.learn:34948), a 
 écrit :
 On Thursday, 19 April 2012 at 18:34:41 UTC, Jacob Carlborg 
 wrote:
 Named arguments would probably be better for this.

 fun(c = 5);

 
 Maybe so, but `fun(c = 5);` is not an additive change, while 
 the OP's suggestion actually is.

 How about

 int c;
 fun(c = 5);

 ?

That is what I was talking about. (did you mean to quote the post 
I quoted, perhaps?)

"bearophile" <bearophileHUGS lycos.com> writes:

ixid:

 fun( , 4, ); //Modifies b
 fun( , , 5); //Modifies c

 for when you want to call fun with other fields not being 
 default? This would seem more flexible and pretty clear what is 
 intended.

I think that for the programmer's eye it's easy to miss one or 
more of those commas, when reading code. So to me something like 
this seems significantly less bug-prone:

fun(void, 4, void); // Modifies b
fun(void, void, 5); // Modifies c

Bye,
bearophile