>> 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
