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

"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 the $@#...

"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
> the $@#...

Admittedly that's a matter of taste!

"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
> > the $@#...
>
> 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! =)

"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
> > > the $@#...
> > 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!

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