Of course. Just at the moment issue: http://d.puremagic.com/issues/show_bug.cgi?id=8441
is holding it back. It will be probably named std.signals2 or something to maintain backwards compatibility, but yeah I definitely want to get it into phobos. In fact, I don't even have a use for it in my own projects, I just saw the current implementation and thought there must be a better way. So the whole point of implementing it, was to get it into phobos. I strongly encourage you to use my implementation, because real world testing before becoming a part of the standard library is always a good idea. But keep in mind, that it wasn't formally reviewed yet so your code might break, when being included into phobos. (Stuff might get renamed for example.) On the other hand fixing this issues should not be too much work. So yeah, please try it out, so it will be perfect when included. The feature set and set of improvements, should be convincing anyway, if not I have done something wrong. As said before, you will have to remove the template mixin at the beginning, (because of the above mentioned bug) and use the struct FullSignal directly. The split up in FullSignal and RestrictedSignal, was to be able to disallow others from emitting the signal. I would be glad to answer any questions about its use and improve documentation where necessary. Best regards, Robert On Sat, 2013-01-19 at 22:47 +0100, David wrote: > Am 19.01.2013 19:39, schrieb eskimo: > > The new implementation offers this possibility, with the strongConnect() > > method. The old implementation wasn't able to do so, because a delegate > > contains no type information about the context. > > > Any plans of getting this into Phobos as a std.signals replacement? > Otherwise using it doesn't make too much sense. (a class is the lesser > of the two evils)
