Doesn't std.signal completely miss the point?

[Johannes Pfau]

Andrej Mitrovic wrote:
>>From what I can tell std.signal is designed around the idea that an
>entire class acts as a signal emitter, without the ability to write
>multiple signals within one class and making arbitrary connections
>between signals and slots.
>
>If you actually read the full paper it links to:
>http://www.elpauer.org/stuff/a_deeper_look_at_signals_and_slots.pdf
>
>you'll see that the idea of signals and slots is to avoid writing
>specialized signal classes, and instead just use member functions as
>signal emitters.
>
>I don't see why we can't have something as good or even better than
>Qt's and Boost's signals and slots implementations. I admit I haven't
>had a look at the other implementations linked from the std.signals
>page yet, so maybe there's some better implementations out there. But
>from a current standpoint it looks to me like std.signal is a good
>candidate for a revamp.

I started a std.signal rewrite ~1 year ago: This is what I came up
with:
http://dl.dropbox.com/u/24218791/d/src/signals.html
https://gist.github.com/1194497

I think the API isn't too bad, but the internal implementation could be
improved. I didn't know about boost.signals, so that could be used to
improve my implementation.

However, I think it's useless as long as it can't be used by multiple
threads. But when I wanted to add 'shared' support to it, I always hit
a dead end, a bug, something not working, so in the end I gave up. 

Another point which could be improved is that it currently only works
for @safe/@trusted delegates. Maybe a @system signal is also useful.
And I'm also not sure how (or whether) signals are meant to be
integrated with message passing.

-- 
Johannes Pfau