Kevin Bealer wrote:

> Since you're thinking about the optionals, I'll mention a "wild idea" I've been thinking about. [...]  My suggestion is that argument lists could be broken up into "stanzas" using ";".  Maybe each set is grouped by function.
> 
> foo(int x, int y, int z = 0; int p, int q, int r = 3);
> 
> Called like this:
> 
> foo(1, 2, 3; 4, 5, 6)
> 
> Or:
> 
> foo(1, 2; 4, 5)

Before thinking about that too deeply, I would rather go for the full solution of named arguments (like in Python). This certainly is a more intrusive language feature which will not be decided overnight, but in the long run, it just is far more powerful, useful and descriptive than such a hard-to-read extension.

In article <c9lb8p$2tm2$2@digitaldaemon.com>, Walter says...
>
>
>"Kevin Bealer" <Kevin_member@pathlink.com> wrote in message news:c9jt8i$pfv$1@digitaldaemon.com...
>> My only reservation is that syntax may be ambiguous, although I can't see
>where
>> it breaks.  Whaddaya think?
>
>There's no technical problem with it, but I'd want to see more demand for it first <g>.

Like I said, just a wild idea, not a feature request.  But optional/default arguments would be really nice, and/or a type safe "va_args" replacement.


Here's another wild idea: a typesafe "..." mechanism.

I'm sure this needs some massaging for performance et al, but the following class is an example of a possible "va" syntax.

Briefly, when a function X uses "...", the system looks for "X_opArg()"
overloads to handle the "..." parts.  Here it is with extended opCall():

class printf2 {
void opCall(int x, ...)
{
printf("%d: ", x);
opArg(...);
printf("\n");
}

void opCall_opArg(char[] x) { printf("%.*s", x); }
void opCall_opArg(double x) { printf("%g", x); }
void opCall_opArg(uint   x) { printf("%d", x); }

void print_two(...);

void print_two_opCall(); // and so on
}

int main()
{
printf_two printf2 = new printf_two;

double dd = 0.345;
uint   uu = 123;

printf2("hello ", dd, " ", uu, "\n");

return 0;
}

I know, printf() is fast, cout slower, so why use seperate calls.  In any case, it would be nice to have some sort of mechanism for this KIND of task, and the function call technique allows a kind of "translation to C object model", because the static type system can already overload in this way.

An alternative would be to only allow this for "opCall" and use "opArg" without any special function name prefix.  If you need more than one extended function, create inner classes, used as data members, to field the calls.

Mostly, I think "..." is currently used for standalone functions anyway, so the hypothetical "printf" here would be a global object or implicit function returning a singleton, etc.

But I think whatever mechanism would need to permit multiple such interfaces per class.

.. Maybe for D v3.0 (cough)?

Kevin