std.signal : voting results

[ilya-stromberg]

On Wednesday, 22 January 2014 at 23:19:08 UTC, David Nadlinger 
wrote:
> This is also the reason why I would have voted "no" if I made 
> it in time. Documentation and implementation can be fixed 
> later, but we would have had to support a borderline-broken API 
> (with regards to type stringification) for the foreseeable 
> future.

The main problem with `std.signal` API is private signals. I 
think it's important feature, but Robert created additional 
struct `Signal`, enum `Protection` and string mixin `signal` to 
implement it.

It's only 2 possible solutions: remove private signals or 
implement new D feature like `friend` keyword.

What can we do? Will we create DIP or bugzilla issue? Andrei, 
what do you think about it?