[Issue 1839] Give D a modern varargs system that allows forwarding

d-bugmail at puremagic.com d-bugmail at puremagic.com
Fri Feb 15 14:32:12 PST 2008


http://d.puremagic.com/issues/show_bug.cgi?id=1839





------- Comment #13 from andrei at metalanguage.com  2008-02-15 16:32 -------
(In reply to comment #10)
> Ok, but it's no longer a function.  I can't do with wrapFn the same things I
> can do with a regular function, namely taking it's address and passing that
> around or calling through it later.  If there were a simple and efficient way
> to convert the wrapsFn template into a function pointer then I'd be satisfied
> with that solution.

I understand, and that's a good point. There can't be a conversion from that
template to a delegate(...) without breaking type safety. 

Here are some other thoughts.

1. The feature you are suggesting offers diminishing returns. It will help
people who:

(a) write a ton of (...) functions so they hate the forwarding idea
(b) don't like macros that would partially automate (a)
(c) call a ton of (...) functions and work so any syntactical burden would be
unacceptable
(d) are in an environment such that template bloat is an issue

There are things that D can't do today, and things that it can do in clunky
ways that are encountered more often than the above. I think it's best we focus
on those first.

2. That being said, I've tried to convice Walter of the utility of the "return
goto" statement, which replaces one function entirely with another. That would
be extremely cheap forwarding for a variety of cases, and would make tail
recursion and mutual recursion obvious and documentable. If that feature were
in, you'd have half of your needed feature:

void foo(...)
{
    ...
}

void callfoo(...)
{
    before();
    return goto foo;
}

You can't do an "after" action because the return goto statement effectively
"execs" foo, and as such callfoo's frame ceases existence. This statement is
easy to typecheck and generates good modular code, but it has certain
limitations (e.g. callfoo cannot have scope() statements, locals with
destructors etc.)

So this feature would cover some things, and yours would cover some overlapping
things. I'm not sure whether either or both have critical mass.


Andrei


-- 



More information about the Digitalmars-d-bugs mailing list