signal slots (new, fixed version)

[Lutger]

Bill Baxter wrote:
  > It seems like having a return value in the slot that differs from the
> return value on the signal results in the slot silently not getting called.
> 
> I'd like to be able to have a Signal!(void,int) but be able to call a 
> method that returns something like "int method(int var)".  A signal with 
> void return should be able to just ignore the return value.
> 
> At the very least the connect attempt should fail if the slot isn't 
> going to actually get called.

I simply didn't think of that, thanks. The connection should fail with a 
compiler message, I'll fix it.

It's possible, although perhaps not very safe, to cast delegates to the 
type the Signal can handle:

signal.connect(cast(signal.DelegateSlot)method); // for delegates
signal.connect(cast(signal.FunctionSlot)&method); // for functions

This could be done inside Signal with parameter type checking, I'll 
consider it.

> Other than that it seems to work pretty well.

Good, thank you for this feedback, I still have to test it better.

> Is there no way the Signals can be initialized automatically?  It's 
> pretty ugly to have to do a new Signal in my constructor for every 
> signal I want to declare.  Actually I was getting crashes for the first 
> little while before I realized I had to do that.
> 
> --bb

I would like that too, but I don't see an acceptable way to do it. A 
signal needs to do some things in the destructor such as notifying 
connected slots it does not exist anymore and freeing memory allocated 
on the C heap. Implementing a signal as a struct instead would require 
to call a deinit() function or something like that which I think is worse.

One thing I was thinking about is to make the signal implementation 
available as a mixin too, with an explicit emit() function instead of 
overloaded opCall. This way you could give a class itself the signal 
functionality without the need for inheritance, in some cases it might 
be more convenient.