std.signals regressions - std.signals2

[David]

>> https://github.com/eskimor/phobos/blob/new_signal/std/signals.d
>>
>> It is completly unusable, "mixin Signal!() x" is blocked by bug, it
>> doesn't compile due to a wrong type (relativly easy fix), then when
>> using -unittest it fails to compile, compiler also doesn't give any
>> hints what exactly fails.
> 
> Current master is an experimental CAS based implementation- untested and
> very likely to get completely reworked internally.

Good to know, but that is already a few monce old, or? I remember seeing
CAS in the code though

>> Removing these unittests makes it at least compile, but the other
>> unittests fail (assert). Removing also these unittests (hoping it still
>> works), nope it doesn't signals aren't triggered at all.
>>
>> Are there any plans on improving this situation with std.signals or the
>> new implementation, currently both are getting less useable every day...
>> (e.g. signal.disconnect(&my_handler) disconnects all, yay what a joy)
> 
> There are plans absolutely, to be concrete: I plan to make it ready in
> July. There is one blocker currently:
> http://d.puremagic.com/issues/show_bug.cgi?id=8441
> 
> but there is already an aging pull request which fixes it:
> 
> https://github.com/D-Programming-Language/dmd/pull/1660 (4 months old
> already)
> 
> I hope it will be merged soon, then there is hopefully nothing that
> hinders my plans. The very least it should become ready during summer.

This blocker wasn't a problem, I used the FullSignal, I can live with
that, I don't like to have a private emit method anyways (in my opinion,
private is always wrong)

>> I am hijacking this thread in hope someone will read that ;)
>> Hopefully also someone of the "new std.signals" developers.
> 
> I almost missed it ;-)
> 
> Sorry about your bad experiences with the current version.

Hehe wouldn't say it is your fault, obviously it worked at some point (I
guess)... I blame DMD, Ranges and the GC of course ;)

- David