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

[d-bugmail at puremagic.com]

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


wbaxter at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |




------- Comment #14 from wbaxter at gmail.com  2008-02-15 17:04 -------
(In reply to comment #13)
> (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

(e) want to have a callback/signal-slot/observer/notification system capable of
using varargs functions as callbacks.

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

Agreed.  I certainly didn't mean to imply by filing this that I thought this
problem should be prioritized over other pressing issues.  But it's something
that I've long found annoying and seen discussed at various time, and yet there
didn't seem to be a bug/enh filed for it yet.

But it seems in conclusion that you agree with me that this should not be
marked "resolved invalid".


--