std.signals and malloc

[eskimo]

No, this would not solve the issue, except you are going to drop weak
ref semantics, which would reduce a signal to a simple array of
delegates and greatly defeats its usefulness. (To prevent memory leaks,
you would have to deregister all your objects from any signals they
might be connected to, when done with an object, which is in some
aspects worse and guaranteed more cumbersome than manual memory
management).

Also see the following announce for the feature set of the new
implementation:
http://forum.dlang.org/thread/mailman.2206.1353757059.5162.digitalmars-d@puremagic.com

If you want to use the new implementation, all you have to do is drop
the template mixin at the beginning and use the FullSignal struct
directly.

A possible workaround for the bug would be to use a string mixin, but
the syntax would become a bit more ugly and we would be locked up with
it then, because a change would break compatibility. 

Any comments about the implementation are appreciated.

Best regards,

Robert

On Thu, 2013-01-17 at 23:33 +0100, David wrote:
> If you tell me that the manual memory management is an old D1 relict
> and
> isn't needed at all, I could clean that code up and submit a pull
> request (I really learned to like std.signals).