std.signals2 proposal

[eskimo]

> Having signals with weak reference semantics can be surprising 
> for a garbage collected language: AFAIK Java and C# use strong 
> reference semantics for observers. On the other hand one may want 
> strong reference semantics: if you have e.g. a button.click 
> listener, you don't want it to die prematurely, do you?

Well I don't think it is a common pattern to create an object, connect
it to some signal and drop every reference to it. On the other hand, if
a signal kept a a strong reference to every object and you are done with
it, you manually have to disconnect it from every signal in order not to
have a memory leak, if the signals are long lived. Which comes pretty
close to manual memory management (You don't get dangling pointers when
doing things wrong, but signals keeping objects alive nobody cares
about). So for me, especially in a garbage collected environment I would
expect not to have to worry about such things.
At least in my understanding it is very unintuitive to have a valid
object whose only reference is a delegate contained in some signal. 

Having said that, there might be good reasons someone wants strong refs,
so I will support in an easy and clean way, also because it comes at
essentially no additional cost. I will just add a method like:

void strongConnnect(void delegate(T1) dg)

with dg being any delegate. (struct member function, lambda, class
member, ...) with obvious semantics.

This way you can use strongConnect if you have an observer you don't
need any reference to, with its lifetime dependent on the signal and use
the normal connect for carefree loose coupling.


Best regards,

Robert