> * 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

On 11/14/13, 8:40 AM, Robert wrote:
>> * 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 }
>

Enums in D may be scoped. There is nothing that prevents you from declaring your enum thus:

enum { protected_, private_, none }

making the shorter version perfectly legal.

mixin(signal!(string, int)("valueChanged", protected_));

Your concern about extra typing by always needing to specify the scope is thus unwarranted.

>
> Enums in D may be scoped. There is nothing that prevents you from declaring your enum thus:
>
> enum { protected_, private_, none }
>
> making the shorter version perfectly legal.
>
> mixin(signal!(string, int)("valueChanged", protected_));
>
> Your concern about extra typing by always needing to specify the scope is thus unwarranted.

This would work, but would make the protection parameter an int. Not really any more beautiful than a string. The advantage of the enum for me was, that it is clear from the signature what are valid protections, this advantage gets lost with an anonymous enum.

The only remaining advantage would be tool support for completion, but I don't think it is worth it.

On Thursday, 14 November 2013 at 15:40:49 UTC, Robert wrote:
>>
>> Enums in D may be scoped. There is nothing that prevents you from declaring your enum thus:
>>
>> enum { protected_, private_, none }
>>
>> making the shorter version perfectly legal.
>>
>> mixin(signal!(string, int)("valueChanged", protected_));
>>
>> Your concern about extra typing by always needing to specify the scope is thus unwarranted.
>
> This would work, but would make the protection parameter an int. Not really any more beautiful than a string. The advantage of the enum for me was, that it is clear from the signature what are valid protections, this advantage gets lost with an anonymous enum.
>
> The only remaining advantage would be tool support for completion, but I don't think it is worth it.

enum Protection { protected_, private_, none }
alias protected_ = Protection.protected_;
alias private_ = Protection.private_;
alias none = Protection.none;

Best of both worlds?

> enum Protection { protected_, private_, none }
> alias protected_ = Protection.protected_;
> alias private_ = Protection.private_;
> alias none = Protection.none;
>
> Best of both worlds?

I thought of this too and it does seem to be a viable solution. I personally really don't mind the string parameter, after all it is a string mixin and it has a default value. But I have to admit, seeing it right in front of me, you got me there, I might like it.

On Thursday, 14 November 2013 at 21:13:24 UTC, Robert wrote:
>> enum Protection { protected_, private_, none }
>> alias protected_ = Protection.protected_;
>> alias private_ = Protection.private_;
>> alias none = Protection.none;
>>
>> Best of both worlds?
>
> I thought of this too and it does seem to be a viable solution. I personally really don't mind the string parameter, after all it is a string mixin and it has a default value. But I have to admit, seeing it right in front of me, you got me there, I might like it.

The only argument against it is namespace pollution.

On Thursday, 14 November 2013 at 21:48:16 UTC, John Colvin wrote:
> On Thursday, 14 November 2013 at 21:13:24 UTC, Robert wrote:
>>> enum Protection { protected_, private_, none }
>>> alias protected_ = Protection.protected_;
>>> alias private_ = Protection.private_;
>>> alias none = Protection.none;
>>>
>>> Best of both worlds?
>>
>> I thought of this too and it does seem to be a viable solution. I personally really don't mind the string parameter, after all it is a string mixin and it has a default value. But I have to admit, seeing it right in front of me, you got me there, I might like it.
>
> The only argument against it is namespace pollution.

There is no such problem in D.

On Thursday, 7 November 2013 at 13:45:57 UTC, Dicebot wrote:
> Our current victim is std.signal by Robert Klotzner which is supposed to deprecate and supersede existing (and broken) std.signals

Robert, it will be great to see some more documentation for `std.signal`.
For example, you can:
 - add more usage examples for each public function
 - add tread-safe example for multi-tread application
 - add better signal description and add more external links (for examle, to the wikipedia - http://en.wikipedia.org/wiki/Signals_and_slots). Look at the old std.signals - http://dlang.org/phobos/std_signals.html

I changed the string mixin now to take an enum instead of the string for specifying the protection. You convinced me, it is just nicer.

 https://vhios.dyndns.org/dlang.org/web/phobos/std_signal.html
 https://github.com/phobos-x/phobosx/blob/master/source/phobosx/signal.d

I will also look into improving documentation a bit soon.

Best regards,
Robert

> Robert, it will be great to see some more documentation for `std.signal`.
> For example, you can:
>  - add more usage examples for each public function
>  - add tread-safe example for multi-tread application
>  - add better signal description and add more external links (for examle, to the wikipedia - http://en.wikipedia.org/wiki/Signals_and_slots). Look at the old std.signals - http://dlang.org/phobos/std_signals.html

On Tuesday, 19 November 2013 at 07:10:32 UTC, Robert wrote:
> I changed the string mixin now to take an enum instead of the string for specifying the protection. You convinced me, it is just nicer.
>
>  https://vhios.dyndns.org/dlang.org/web/phobos/std_signal.html
>  https://github.com/phobos-x/phobosx/blob/master/source/phobosx/signal.d
>
> I will also look into improving documentation a bit soon.
>
> Best regards,
> Robert
>
>> Robert, it will be great to see some more documentation for `std.signal`.
>> For example, you can:
>> - add more usage examples for each public function
>> - add tread-safe example for multi-tread application
>> - add better signal description and add more external links (for examle, to the wikipedia - http://en.wikipedia.org/wiki/Signals_and_slots). Look at the old std.signals - http://dlang.org/phobos/std_signals.html

Thanks!

Looks there are no real objections against the proposal but I am rather concerned about general lack of activity during review. As a compromise, what about putting it in "candidate" category (http://code.dlang.org/?sort=updated&category=library.std_aspirant) and making 1-2 month pause before proceeding to actual voting? That will also fix minor issue of me being a bit busy and not paying proper attention :)