Review of std.signal

[Robert]

> * If a template mixin, which uses the string mixin, is provided 
> the syntax will look a bit nicer

It does, as it saves two to four brackets for multi arg signals, 
I nevertheless decided against it for the following reasons:

1. Despite being a little more verbose, I like its style better. 
Maybe because the name of the signal is separate from its 
parameter types, providing a bit more structure.

2. Naming problem. The template would have to start with a 
capital letter according to the D style rules, thus it would 
clash with the struct Signal. I could name it Sig or something or 
rename the struct. A stupid reason, but it troubles me a bit.

3. It is just another level of indirection making it arguably 
harder to understand what is going on: template mixin -> string 
mixin -> struct.

>
> * Isn't it better to use an enum for the protection attributes?

Having put some thought into this, while it seems to be, I think 
it isn't.
Enums in D are scoped, so for the enum:

enum Protection { protected_, private_, none }

The syntax gets more verbose instead of less:
  mixin(signal!(string, int)("valueChanged", 
Protection.protected_));
instead of:
  mixin(signal!(string, int)("valueChanged", "protected"));

Also you can use the keyword as is and as every programmer is 
used to. Pro enum would be tool support (auto completion) but I 
suppose people would almost always use the default anyway and if 
they don't, typing "protected" by hand is not really a challenge.

But thanks for the suggestions, I had not even thought about the 
wrapping template mixin before.

If you or someone else are really unhappy with those decisions, 
feel free to argue against them ;-) .

Best regards,

Robert