std.signals2 proposal

[eskimo]

> I've not read the code and I'm not 100% sure of the intentions of 
> std.signal but why not just call the delegate as is?
> 

Signals are a way of a very loose coupling of components. This loose
coupling is the reason why people usually expect weak reference
semantics from signals. So people expect a signal connection to simply
vanish when the observer object dies, instead of keeping it alive
because it holds a reference to it.

The solution at the moment is to hold a reference to the object in
memory not seen by the gc. So it gets destroyed if no one else holds a
reference. But to avoid calling a dead object's method the signal needs
to be notified about this, which is currently only possible for objects.
(so no generic delegate support)

The only reason why a simple delegate is not enough, is the weak
reference semantics. If it was not for that, a signal would just be a
simple array of delegates.

Things get even more complex if you allow wrapper delegates. That's
because you have to keep the wrapper delegates context in memory even if
nobody else references it. Thus you need a strong ref to the delegates
context and a weak ref to the target object, that's why the target
object is passed to the delegate, instead of simply containing a ref in
the context pointer.

The new implementation supports wrapper delegates, the old one does not
and can't with the current API. If we had generic weak references and
you would pass a lamda to connect, (which would be syntactically
correct), the connection would be gone on the next gc collect cycle. 

The reason I think wrapper delegates are really needed is that signals,
as already mentioned, are a way of loose coupling. If the signatures of
signal and final receiver have to match exactly, the usefulness is
seriously limited. And very powerful and elegant techniques are possible
if you can pass arbitrary parameters to a slot via the delegate. A very
simple example with button.clicked & addNumber was already presented in
may first e-mail on this topic, but it is really just the top of the
iceberg.

Almost every signal/slot implementation has weak reference semantics,
the only one I found not having weak reference semantics was the
implementation in Tango, but only because D has no weak references. In
some occasions weak reference semantics might not needed (if you have
objects connected together with similar life times), but a general
working approach should support weak coupling, otherwise you could
simply use a delegate array.