Here's a spin on that idea that allows the delegate to take an Event
parameter, or not, as it wishes. This one uses a factory function,
which I think is the way to go, because that enables IFTI for the
parameter types.
....

Is such a hack really nessesary ? ( ... Sorry ... )
I mean A look at old school Smalltalk's message handling should teach
us that "code blocks" // in our D case : closures // enable us to find a
smarter solution. So I vote for spending a reasonable amount of time
to figure out either a good/better D-ish solution or give a smalltalk
like solution a try.
Just my unholy opinion / the current DWT event handling is a bit clumbsy.
->
Well, Closures are a D2 feature . and implementing code blocks using
closures is not very smart .. THough I'm conviced that a closure
based solution is worth thinking twice...
OT ---------------------------------------
D blocks : Pseudo code
------------------------------------------
for_each = function (list, block)
{
for (i = 0; i < list.sizeof(); ++i)
block(list[i])
}
list = #(12, 34, 56) // tuple
for_each(list)
{ |x| Print(x) }
=> 12
34
56

I don't get what your example shall illustrate.
Can you explain a bit more verbose?

Bjoern, I don't really get what you're saying either, but it sounds
vaguely like you're saying let's make delegates be usable as event handlers.
That's basically what this adapter template does. It lets you say :
setListener(dgWrapper(
(Event ev) { Print(ev); }
));
Instead of:
setListener(new class Listener {
void handleEvent(Event ev) {
Print(ev);
}
});
The next step would be to add an override to the setListener method to
take a delegate and create the _DgListenerWrapperT automatically under
the hood. Then you could do:
setListener(
(Event ev) { Print(ev); }
)
but that wouldn't allow passing the extra args.
--bb