• Taylor Gautier (45/45) Aug 17 2001 I scanned through the docs for D, looks pretty cool! I didn't see a lot...
• Russ Lewis (7/52) Aug 17 2001 I would think that a call like
• Russ Lewis (3/5) Aug 17 2001 should be: f.do_some_foo(12,default,6)
• Christophe de Dinechin (48/61) Aug 18 2001 I believe you meant
• Taylor Gautier (19/39) Aug 20 2001 DEFAULT_C_VAL);
• Walter (9/20) Aug 18 2001 No. The behavior can be duplicated with:
• Taylor Gautier (26/46) Aug 20 2001 Hmmm :(
• Dan Hursh (28/53) Aug 24 2001 Mind if I ask what weirdness there is? (aside from the possible
• Walter (12/63) Aug 31 2001 The wierdness comes from how overloading works, and what happens when yo...
• Sean L. Palmer (31/40) Oct 23 2001 I've seen plenty. Something like this perhaps:
• Sean L. Palmer (28/69) Oct 23 2001 In fact I'd like to see the ability to default-initialize members at poi...
• Walter (20/96) Dec 30 2001 (when
• Pavel Minayev (12/14) Dec 31 2001 I don't really see any big "trouble". It's just a matter of decision -
• Walter (5/9) Dec 31 2001 Yes, it does work in C++, but at the cost of complicated and non-obvious
• Pavel Minayev (7/13) Dec 31 2001 If this really is an issue, forbid overloading of functions with
• Walter (10/23) Dec 31 2001 That is a good thought.
• Pavel Minayev (10/17) Jan 01 2002 10

"Taylor Gautier" <tgautier yahoo.com> writes:

I scanned through the docs for D, looks pretty cool!  I didn't see a lot of
documentation regarding functions so I'll ask one question, and make a
suggestion too.  If these were already in the documenation, I apologize in
advance!

1) Are there default values allowed for functions?  With the strong
influence of C/C++ on D, I would imagine so.

2) After reading the following section regarding static initialization of
structs in any order, a thought occurred to me about the usefulness of this
construct:

~ D documentation
Static struct members are by default initialized to 0, and floating point
values to NAN. If a static initializer is supplied, the members are
initialized by the member name, colon, expression syntax. The members may be
initialized in any order.
 struct X { int a; int b; int c; int d = 7;}
 static X x = { a:1, b:2}; // c is set to 0, d to 7
 static X z = { c:4, b:5, a:2 , d:5};   // z.a = 2, z.b = 5, z.c = 4, d = 5
~

How many times have you written a function like (ok, this is c++ like
syntax, bear with me):

class foo
{
    ...
    void do_some_foo(int a, int b = DEFAULT_B_VAL, int c = DEFAULT_C_VAL);
};

But then, you wanted to call do_some_foo() with the value a, and the value
c, but use the default value for b.  It turns out that in practice,
functions with more than 1 default value are generally not as useful as
functions with 1 default value, because with 2 or more default values, you
generally end up wanting to specify each of the two values independently
while leaving the other to be the default value in different places in your
code, yet this is not possible. (it get's worse with more defaults)

Combining this wish (to have independent default values) with a nice little
perl-ism that allows for named parameters [ala lincoln stein's CGI.pm and
probably others] *and* with D's static struct initialization syntax,
couldn't the calling syntax for functions be enhanced in general to allow
for the arbitrary ordering of parameters, so long as you named them?

This would allow you to call:

int main()
{
    foo f;

    f.do_some_foo(a:12, c:6);

   // which should be equivalent to:

   f.do_some_foo(12, c:6);
}

Russ Lewis <russ deming-os.org> writes:

Taylor Gautier wrote:

 I scanned through the docs for D, looks pretty cool!  I didn't see a lot of
 documentation regarding functions so I'll ask one question, and make a
 suggestion too.  If these were already in the documenation, I apologize in
 advance!

 1) Are there default values allowed for functions?  With the strong
 influence of C/C++ on D, I would imagine so.

 2) After reading the following section regarding static initialization of
 structs in any order, a thought occurred to me about the usefulness of this
 construct:

 ~ D documentation
 Static struct members are by default initialized to 0, and floating point
 values to NAN. If a static initializer is supplied, the members are
 initialized by the member name, colon, expression syntax. The members may be
 initialized in any order.
  struct X { int a; int b; int c; int d = 7;}
  static X x = { a:1, b:2}; // c is set to 0, d to 7
  static X z = { c:4, b:5, a:2 , d:5};   // z.a = 2, z.b = 5, z.c = 4, d = 5
 ~

 How many times have you written a function like (ok, this is c++ like
 syntax, bear with me):

 class foo
 {
     ...
     void do_some_foo(int a, int b = DEFAULT_B_VAL, int c = DEFAULT_C_VAL);
 };

 But then, you wanted to call do_some_foo() with the value a, and the value
 c, but use the default value for b.  It turns out that in practice,
 functions with more than 1 default value are generally not as useful as
 functions with 1 default value, because with 2 or more default values, you
 generally end up wanting to specify each of the two values independently
 while leaving the other to be the default value in different places in your
 code, yet this is not possible. (it get's worse with more defaults)

 Combining this wish (to have independent default values) with a nice little
 perl-ism that allows for named parameters [ala lincoln stein's CGI.pm and
 probably others] *and* with D's static struct initialization syntax,
 couldn't the calling syntax for functions be enhanced in general to allow
 for the arbitrary ordering of parameters, so long as you named them?

 This would allow you to call:

 int main()
 {
     foo f;

     f.do_some_foo(a:12, c:6);

    // which should be equivalent to:

    f.do_some_foo(12, c:6);
 }

I would think that a call like

    f.do_some_foo(a,,c)

would be more readable, but I'm not sure that it is worth it.  Too much
possibility of syntax errors or bugs from hitting , too many times.  What about:

    f.do_some_foo(a,default,c)

I dunno if I really like it.  Just brainstorming...thoughts, anyone?

Russ Lewis <russ deming-os.org> writes:

My mistake.  Used wrong values in my previous post...

     f.do_some_foo(a,,c)

should be:   f.do_some_foo(12,,6)

     f.do_some_foo(a,default,c)

should be:   f.do_some_foo(12,default,6)

Christophe de Dinechin <descubes earthlink.net> writes:

Taylor Gautier wrote:

 class foo
 {
     ...
     void do_some_foo(int a, int b = DEFAULT_B_VAL, int c = DEFAULT_C_VAL);
 };

 This would allow you to call:

 int main()
 {
     foo f;

     f.do_some_foo(a:12, c:6);

    // which should be equivalent to:

    f.do_some_foo(12, c:6);
 }

I believe you meant

    f.do_some_foo(12, DEFAULT_B_VAL, 6)


First point: LX has that very feature:

[localhost:~/Development/mozart/lx] ddd% cat test.lx
function f(integer A := 0, B := 1, C := 2) return integer

integer A := f()
integer B := f(1)
integer C := f(2, 3)
integer D := f(C: 4)
integer E := f(B: 1, C: 2, A: 0)


[localhost:~/Development/mozart/lx] ddd% ./lx -parse test.lx -run_semantics
-stdout
-- Generated by LX using lx-text.stylesheet
import  LX_BUILTINS
using LX_BUILTINS

constant  function f( in _integer A := 0;  in _integer B := 1;
                      in _integer C := 2) return _integer
variable  _integer A := f (0, 1, 2)
variable  _integer B := f (1, 1, 2)
variable  _integer C := f (2, 3, 2)
variable  _integer D := f (0, 1, 4)
variable  _integer E := f (0, 1, 2)
-- Thank you for using LX.
[localhost:~/Development/mozart/lx] ddd%



Second point: did you know that a little known "feature" of C++ in that space
allows you to write code that becomes invalid if you _include_ a header file
(not that most C++ compiler care...) The C++ rules are that default arguments
from multiple declarations combine, but that they must not overlap. And also,
there must be a default for argument for arg[N+1] if there is one for arg[N].
So:

// file1.C
int f(int x = 0, int y);    // NO: default required for y

// file2.C
int f(int x, int y = 0);
int f(int x = 0, int y);    // OK: both have defaults

// file3.C
int f(int x = 0, int y = 0);
int f(int x = 0, int y);    // NO: two defaults for x


Notice how the _EXACT SAME DEFINITION_ becomes invalid depending on the
context. If you have a compiler that cares about these rules, you can misuse
them for really great "mysterious error of the day" jokes. In particular, have
declarations that compile either only when the header is included, or
alternatively, only when the header is _NOT_ included, or even combinations
where some headers have to be included in a very specific order. All this
without even using the preprocessor.

Conclusion: beware of the exact rules in D :-)


Christophe

"Taylor Gautier" <tgautier yahoo.com> writes:

"Christophe de Dinechin" <descubes earthlink.net> wrote in message
news:3B7E2161.C752432D earthlink.net...
 Taylor Gautier wrote:

 class foo
 {
     ...
     void do_some_foo(int a, int b = DEFAULT_B_VAL, int c =


DEFAULT_C_VAL);
 };

 This would allow you to call:

 int main()
 {
     foo f;

     f.do_some_foo(a:12, c:6);

    // which should be equivalent to:

    f.do_some_foo(12, c:6);
 }

 I believe you meant

     f.do_some_foo(12, DEFAULT_B_VAL, 6)

You missed my point.  I did NOT mean

f.do_some_foo(12, DEFAULT_B_VAL, 6);

I wrote:

f.do_some_foo(12, c:6)

on purpose for precisely the reason that I DON'T want to have to know what
DEFAULT_B_VAL is defined to be.  (Sure if it's a constant, that's nice, but
what if it isn't?)

I don't want D to have C++ semantics, I would like for D to have something
more advanced than that.

I understand the rules surrounding default values that you mention in your
response.  It is precisely these rules that are limiting and confusing.  I
would like, for instance, a way to specify all 9 parameters to a function to
have some reasonable defaults, and to be able to call that function
specifying values for say any 2 input parameters. This type of thing is
simply not possible with C++ rules/syntax.

-t

"Walter" <walter digitalmars.com> writes:

Taylor Gautier wrote in message <9ljqh1$25ki$1 digitaldaemon.com>...
I scanned through the docs for D, looks pretty cool!  I didn't see a lot of
documentation regarding functions so I'll ask one question, and make a
suggestion too.  If these were already in the documenation, I apologize in
advance!
1) Are there default values allowed for functions?  With the strong
influence of C/C++ on D, I would imagine so.


No. The behavior can be duplicated with:

    void foo(int x, int y) { ... }
    void foo(int x) { foo(x, 3); }

so there's no need for it or all the weird consequences of it.



Combining this wish (to have independent default values) with a nice little
perl-ism that allows for named parameters [ala lincoln stein's CGI.pm and
probably others] *and* with D's static struct initialization syntax,
couldn't the calling syntax for functions be enhanced in general to allow
for the arbitrary ordering of parameters, so long as you named them?


I've needed the named initialization thing with structs because I've dealt
with structs with dozens of members. While function parameters are
technically the same concept, I just don't come across functions with dozens
of parameters.

"Taylor Gautier" <tgautier yahoo.com> writes:

Hmmm :(

Well, I imagine one day in D you might see:

class foo
{
    struct bar_args { int a; int b; int c; int d = 7;};
    void bar(bar_args args);
};

void main()
{
    bar(foo::bar_args{a:1, b:2});
}

Or something equivalent (not sure if that's 100% syntactically correct) hehe
:)

I've seen the need for a lot of parameters when building CGI/HTML
programming aids (which is why I mentioned CGI.pm) where tons of input
parameters can abound, generally with reasonable defaults to all of them.

You can always design around functions with a lot of parameters, but I don't
think a language should force you to design around anything, yes? (I assume
it's why you started D)

-t

"Walter" <walter digitalmars.com> wrote in message
news:9ln6rh$1b8b$2 digitaldaemon.com...
 Taylor Gautier wrote in message <9ljqh1$25ki$1 digitaldaemon.com>...
I scanned through the docs for D, looks pretty cool!  I didn't see a lot


of
documentation regarding functions so I'll ask one question, and make a
suggestion too.  If these were already in the documenation, I apologize


in
advance!
1) Are there default values allowed for functions?  With the strong
influence of C/C++ on D, I would imagine so.


 No. The behavior can be duplicated with:

     void foo(int x, int y) { ... }
     void foo(int x) { foo(x, 3); }

 so there's no need for it or all the weird consequences of it.



Combining this wish (to have independent default values) with a nice


little
perl-ism that allows for named parameters [ala lincoln stein's CGI.pm and
probably others] *and* with D's static struct initialization syntax,
couldn't the calling syntax for functions be enhanced in general to allow
for the arbitrary ordering of parameters, so long as you named them?


 I've needed the named initialization thing with structs because I've dealt
 with structs with dozens of members. While function parameters are
 technically the same concept, I just don't come across functions with

dozens
 of parameters.

Dan Hursh <hursh infonet.isl.net> writes:

Walter wrote:
 
 Taylor Gautier wrote in message <9ljqh1$25ki$1 digitaldaemon.com>...
I scanned through the docs for D, looks pretty cool!  I didn't see a lot of
documentation regarding functions so I'll ask one question, and make a
suggestion too.  If these were already in the documenation, I apologize in
advance!
1) Are there default values allowed for functions?  With the strong
influence of C/C++ on D, I would imagine so.

 
 No. The behavior can be duplicated with:
 
     void foo(int x, int y) { ... }
     void foo(int x) { foo(x, 3); }
 
 so there's no need for it or all the weird consequences of it.

	Mind if I ask what weirdness there is?  (aside from the possible
overlap of function declarations?)  I'm a novice, so if it's too complex
to explain in a meaningful way, don't worry.
	It's handy feature but your example demonstrated that it isn't that
handy by itself.  At least the default value is reflected in the
declaration of the function.  Some object browsers could use that.  But
it would probably be unpleasant to see if there is an f(int x = 0) and
an f().
 
Combining this wish (to have independent default values) with a nice little
perl-ism that allows for named parameters [ala lincoln stein's CGI.pm and
probably others] *and* with D's static struct initialization syntax,
couldn't the calling syntax for functions be enhanced in general to allow
for the arbitrary ordering of parameters, so long as you named them?

 
 I've needed the named initialization thing with structs because I've dealt
 with structs with dozens of members. While function parameters are
 technically the same concept, I just don't come across functions with dozens
 of parameters.

If you had the above feature, this would be very beautiful.  Given named
parameters and the ability to set defaults for a scope would be even
nicer,


	import guiApi; // for the draw method

	// declare a local set of defaults
	return_t draw(window_t w = mywindow, color fg = myfg, color bg = mybg,
		      drawable d, position_t p, scale_t s = 1.0, 
		      rotation_t r = 0.0);

	// draw a box
	draw(d:mybox p:here);

	// draw a diamond
	draw(d:mybox p:there r:(PI/4));

	
I will say that I wouldn't see named parameter as being too useful
without some sort of declared parameter defaults.  I supposed I should
shut up so you can spend more time on the compiler instead of dealing
with my odd suggestions.

Dan

"Walter" <walter digitalmars.com> writes:

The wierdness comes from how overloading works, and what happens when you
inherit and override the function. You have to come up with some convoluted
rules that wind up being confusing to many programmers.

-Walter

Dan Hursh wrote in message <3B873BB4.287DE4FA infonet.isl.net>...
Walter wrote:
 Taylor Gautier wrote in message <9ljqh1$25ki$1 digitaldaemon.com>...
I scanned through the docs for D, looks pretty cool!  I didn't see a lot



of
documentation regarding functions so I'll ask one question, and make a
suggestion too.  If these were already in the documenation, I apologize



in
advance!
1) Are there default values allowed for functions?  With the strong
influence of C/C++ on D, I would imagine so.

 No. The behavior can be duplicated with:

     void foo(int x, int y) { ... }
     void foo(int x) { foo(x, 3); }

 so there's no need for it or all the weird consequences of it.

 Mind if I ask what weirdness there is?  (aside from the possible
overlap of function declarations?)  I'm a novice, so if it's too complex
to explain in a meaningful way, don't worry.
 It's handy feature but your example demonstrated that it isn't that
handy by itself.  At least the default value is reflected in the
declaration of the function.  Some object browsers could use that.  But
it would probably be unpleasant to see if there is an f(int x = 0) and
an f().

Combining this wish (to have independent default values) with a nice



little
perl-ism that allows for named parameters [ala lincoln stein's CGI.pm



and
probably others] *and* with D's static struct initialization syntax,
couldn't the calling syntax for functions be enhanced in general to



allow
for the arbitrary ordering of parameters, so long as you named them?

 I've needed the named initialization thing with structs because I've


dealt
 with structs with dozens of members. While function parameters are
 technically the same concept, I just don't come across functions with


dozens
 of parameters.

If you had the above feature, this would be very beautiful.  Given named
parameters and the ability to set defaults for a scope would be even
nicer,


 import guiApi; // for the draw method

 // declare a local set of defaults
 return_t draw(window_t w = mywindow, color fg = myfg, color bg = mybg,
       drawable d, position_t p, scale_t s = 1.0,
       rotation_t r = 0.0);

 // draw a box
 draw(d:mybox p:here);

 // draw a diamond
 draw(d:mybox p:there r:(PI/4));


I will say that I wouldn't see named parameter as being too useful
without some sort of declared parameter defaults.  I supposed I should
shut up so you can spend more time on the compiler instead of dealing
with my odd suggestions.

Dan

"Sean L. Palmer" <spalmer iname.com> writes:

Combining this wish (to have independent default values) with a nice


little
perl-ism that allows for named parameters [ala lincoln stein's CGI.pm and
probably others] *and* with D's static struct initialization syntax,
couldn't the calling syntax for functions be enhanced in general to allow
for the arbitrary ordering of parameters, so long as you named them?

 I've needed the named initialization thing with structs because I've dealt
 with structs with dozens of members. While function parameters are
 technically the same concept, I just don't come across functions with

dozens
 of parameters.

I've seen plenty.  Something like this perhaps:

void DrawTexturedQuad(Texture* texture, float z, float alpha,
                                       Point3 pul, Point3 pur, Point3 pll,
Point3 plr,
                                       Point2 uvul, Point2 uvur, Point2
uvll, Point2 uvlr,
                                       Color cul, Color cur, Color cll,
Color clr);

That's 15... And that only looks worse if some schmuck isn't using Point and
Color classes.  Of course it could be cleaned up by making Vertex objects
instead of separate Points and Colors, but D isn't supposed to enforce good
programming, but encourage it.  Every project has stages where you just need
something *now* and have to break a few rules temporarily.

Usually in those quick cases where you need to keep adding features to some
existing interface, eventually it becomes unwieldy... you may consider me a
bad programmer for it, but it's either that or do one of two things:

A) make a struct for the values and pass the struct as a parameter.  This
makes the code really ugly.  Microsoft does it in their API's, so it must be
wrong, no?  ;)

B) break the interface up into multiple SetState() functions and a final
Execute() function.  This may not apply well to all problems.

It's not going to hurt anything to allow arbitrary parameter defaults (you
could re-use the default keyword if you don't like the
bunch-of-consecutive-commas solution) and it could be quite convenient for
interface-user side code self-documentation to allow naming arguments to
functions.  Alot nicer than in C/C++ as those languages allow multiple
forward declarations, each with potentially different names for the
arguments.

Sean

"Sean L. Palmer" <spalmer iname.com> writes:

 1) Are there default values allowed for functions?  With the strong
 influence of C/C++ on D, I would imagine so.

In fact I'd like to see the ability to default-initialize members at point
of declaration, like so:

class Foo
{
  private:
    static int usage = 0;  // this assignment happens before main()
    int count = 1;           // this happens before any ctors are run (when
vtable is being initialized, probably)
    const char[] name = "unnamed"; // default ctor below won't use this
default value cuz compiler can tell name gets assigned before it gets read.
  public:
    Foo() { name = "Foo"; } // but count gets initialized to 1 first
}

Whaddya think, Walter?

 2) After reading the following section regarding static initialization of
 structs in any order, a thought occurred to me about the usefulness of

this
 construct:

 ~ D documentation
 Static struct members are by default initialized to 0, and floating point
 values to NAN. If a static initializer is supplied, the members are
 initialized by the member name, colon, expression syntax. The members may

be
 initialized in any order.
  struct X { int a; int b; int c; int d = 7;}
  static X x = { a:1, b:2}; // c is set to 0, d to 7
  static X z = { c:4, b:5, a:2 , d:5};   // z.a = 2, z.b = 5, z.c = 4, d =

5
 ~

 How many times have you written a function like (ok, this is c++ like
 syntax, bear with me):

 class foo
 {
     ...
     void do_some_foo(int a, int b = DEFAULT_B_VAL, int c = DEFAULT_C_VAL);
 };

 But then, you wanted to call do_some_foo() with the value a, and the value
 c, but use the default value for b.  It turns out that in practice,
 functions with more than 1 default value are generally not as useful as
 functions with 1 default value, because with 2 or more default values, you
 generally end up wanting to specify each of the two values independently
 while leaving the other to be the default value in different places in

your
 code, yet this is not possible. (it get's worse with more defaults)

 Combining this wish (to have independent default values) with a nice

little
 perl-ism that allows for named parameters [ala lincoln stein's CGI.pm and
 probably others] *and* with D's static struct initialization syntax,
 couldn't the calling syntax for functions be enhanced in general to allow
 for the arbitrary ordering of parameters, so long as you named them?

 This would allow you to call:

 int main()
 {
     foo f;

     f.do_some_foo(a:12, c:6);

    // which should be equivalent to:

    f.do_some_foo(12, c:6);
 }

I actually think this second point is a good idea too.

Just thought of something silly.  If you have  ? :  operators, you wouldn't
need if or else keywords so long as you can treat a block as having a void
value, and make  ? :  accept void values as its second and third arguments.
Of course is one was void the other'd have to also be void.  Can't think of
an equivalent for while.  ;)

I wonder what a language which didn't differentiate between a statement,
block, or expression would be like?

Sean

"Walter" <walter digitalmars.com> writes:

"Sean L. Palmer" <spalmer iname.com> wrote in message
news:9r37dh$6j5$1 digitaldaemon.com...
 In fact I'd like to see the ability to default-initialize members at point
 of declaration, like so:
 class Foo
 {
   private:
     static int usage = 0;  // this assignment happens before main()
     int count = 1;           // this happens before any ctors are run

(when
 vtable is being initialized, probably)
     const char[] name = "unnamed"; // default ctor below won't use this
 default value cuz compiler can tell name gets assigned before it gets

read.
   public:
     Foo() { name = "Foo"; } // but count gets initialized to 1 first
 }

 Whaddya think, Walter?

It's already implemented!


 2) After reading the following section regarding static initialization


of
 structs in any order, a thought occurred to me about the usefulness of

 this
 construct:

 ~ D documentation
 Static struct members are by default initialized to 0, and floating


point
 values to NAN. If a static initializer is supplied, the members are
 initialized by the member name, colon, expression syntax. The members


may
 be
 initialized in any order.
  struct X { int a; int b; int c; int d = 7;}
  static X x = { a:1, b:2}; // c is set to 0, d to 7
  static X z = { c:4, b:5, a:2 , d:5};   // z.a = 2, z.b = 5, z.c = 4, d


=
 5
 ~

 How many times have you written a function like (ok, this is c++ like
 syntax, bear with me):

 class foo
 {
     ...
     void do_some_foo(int a, int b = DEFAULT_B_VAL, int c =


DEFAULT_C_VAL);
 };

 But then, you wanted to call do_some_foo() with the value a, and the


value
 c, but use the default value for b.  It turns out that in practice,
 functions with more than 1 default value are generally not as useful as
 functions with 1 default value, because with 2 or more default values,


you
 generally end up wanting to specify each of the two values independently
 while leaving the other to be the default value in different places in

 your
 code, yet this is not possible. (it get's worse with more defaults)

 Combining this wish (to have independent default values) with a nice

 little
 perl-ism that allows for named parameters [ala lincoln stein's CGI.pm


and
 probably others] *and* with D's static struct initialization syntax,
 couldn't the calling syntax for functions be enhanced in general to


allow
 for the arbitrary ordering of parameters, so long as you named them?

 This would allow you to call:

 int main()
 {
     foo f;

     f.do_some_foo(a:12, c:6);

    // which should be equivalent to:

    f.do_some_foo(12, c:6);
 }

 I actually think this second point is a good idea too.

The trouble with default parameters is all the special rules necessary to
deal with inheritance and overloading.


 Just thought of something silly.  If you have  ? :  operators, you

wouldn't
 need if or else keywords so long as you can treat a block as having a void
 value, and make  ? :  accept void values as its second and third

arguments.
 Of course is one was void the other'd have to also be void.  Can't think

of
 an equivalent for while.  ;)

 I wonder what a language which didn't differentiate between a statement,
 block, or expression would be like?

lisp? <g>

"Pavel Minayev" <evilone omen.ru> writes:

"Walter" <walter digitalmars.com> wrote in message
news:a0o6ml$shs$1 digitaldaemon.com...

 The trouble with default parameters is all the special rules necessary to
 deal with inheritance and overloading.

I don't really see any big "trouble". It's just a matter of decision -
your decision. Whether you make default parameters inheritable and
(or) overridable (personally I'd prefer both), they're still damn
useful. Overloading should, IMO, treat generic functions as if their
default parameters are missing:

    int seek(int offset);
    int seek(int offset, int rel = 0);    // hey not so fast!

All this works in C++ quite well, why not in D? Yes, you've told that
it can be achieved by function overloading, but it's such a pain in

"Walter" <walter digitalmars.com> writes:

"Pavel Minayev" <evilone omen.ru> wrote in message
news:a0paea$1ieb$1 digitaldaemon.com...
 All this works in C++ quite well, why not in D?

Yes, it does work in C++, but at the cost of complicated and non-obvious
rules.

 Yes, you've told that
 it can be achieved by function overloading, but it's such a pain in


Admittedly that's a matter of taste!

"Pavel Minayev" <evilone omen.ru> writes:

"Walter" <walter digitalmars.com> wrote in message
news:a0q9d2$24bg$1 digitaldaemon.com...

 Yes, it does work in C++, but at the cost of complicated and non-obvious
 rules.

If this really is an issue, forbid overloading of functions with
default parameters at all! I personally don't remember the case
where I mixed these - overloading and optional arguments - at all.

 Yes, you've told that
 it can be achieved by function overloading, but it's such a pain in


 Admittedly that's a matter of taste!

 Even if the function has 10 parameters, nine of which are optional?
I imagine having to type nine more functions just to do that...grr! =)

"Walter" <walter digitalmars.com> writes:

"Pavel Minayev" <evilone omen.ru> wrote in message
news:a0qaja$2565$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:a0q9d2$24bg$1 digitaldaemon.com...
 Yes, it does work in C++, but at the cost of complicated and non-obvious
 rules.

 If this really is an issue, forbid overloading of functions with
 default parameters at all! I personally don't remember the case
 where I mixed these - overloading and optional arguments - at all.

That is a good thought.

 Yes, you've told that
 it can be achieved by function overloading, but it's such a pain in


 Admittedly that's a matter of taste!

  Even if the function has 10 parameters, nine of which are optional?
 I imagine having to type nine more functions just to do that...grr! =)

In my work, I've rarely encountered a case with more than one optional
parameter, which is easilly covered by a wrapper function. Have you seen 10
parameters with 9 defaults? For my own code, I used default arguments for a
while, and then took them out. I admit it's a matter of taste.

Keep in mind that nothing in D will prevent adding default parameters in
future versions of the language. Right now I'm trying to get what I have to
work!

"Pavel Minayev" <evilone omen.ru> writes:

"Walter" <walter digitalmars.com> wrote in message
news:a0r7nr$2lbr$1 digitaldaemon.com...

 In my work, I've rarely encountered a case with more than one optional
 parameter, which is easilly covered by a wrapper function. Have you seen

10
 parameters with 9 defaults? For my own code, I used default arguments for

a
 while, and then took them out. I admit it's a matter of taste.

A good example of what _potentially_ could use optional arguments
is Windows API. Frequently, only one or two arguments are important,
and others - which can be 5 or 6 - are nulls or something like that.

 Keep in mind that nothing in D will prevent adding default parameters in
 future versions of the language. Right now I'm trying to get what I have

to
 work!

Yes, sure. I don't ask to include it into the language immediately.
But it's not in the specs, so I wanted to make the subject clear...