Re: Review of std.signal

[Robert]

I was referring to the issue of string mixin vs mixin template.

My bad ;-) My first implementation was using just a template 
mixin, but I hit a few bugs (At least 2, one should be fixed 
already the other one I can't remember, but had something to do 
with derived classes), so I tried the string mixin approach and I 
have to admit, that I like it more now, regardless of template 
mixin bugs. The added flexibility of choosing the protection is a 
big win as it is not that unlikely that someone wants for example 
derived classes being able to emit the signal.

Another minor drawback of the template mixin, is that I have to 
wrap all struct members into mixin functions*) and the actual 
struct would need to be renamed into something less straight 
forward too.

Best regards,
Robert

*) Without wrapping, using the signal would be more ugly, 
something like:

class Test {
 mixin Signal!int a;
 mixin(signal!int("b"));
 void doSomething() {
     // something
     a.signal.emit(4);
     // vs
     b.emit(4);
 }
}