Thread overview
Deprecate std.signals?
Mar 30
Berni44
Mar 30
Clint E.
Apr 12
Berni44
March 30
I've got the feeling, that std.signals is rarely used and not up to D's standards... Therefore I suggest to move it to undead and deprecate it.

But I might err on this. What do you think?
March 30
On Tue, Mar 30, 2021 at 11:23:21AM +0000, Berni44 via Digitalmars-d wrote:
> I've got the feeling, that std.signals is rarely used and not up to D's standards... Therefore I suggest to move it to undead and deprecate it.
> 
> But I might err on this. What do you think?

Yes.


T

-- 
It said to install Windows 2000 or better, so I installed Linux instead.
March 30
On Tuesday, 30 March 2021 at 11:23:21 UTC, Berni44 wrote:
> I've got the feeling, that std.signals is rarely used and not up to D's standards... Therefore I suggest to move it to undead and deprecate it.
>
> But I might err on this. What do you think?

Go ahead make my day!

Clint.
April 04

On Tuesday, 30 March 2021 at 11:23:21 UTC, Berni44 wrote:

>

I've got the feeling, that std.signals is rarely used and not up to D's standards... Therefore I suggest to move it to undead and deprecate it.

But I might err on this. What do you think?

I might be able to provide some background on this.

Prior to becoming a D convert I used to program in C++, and Qt was the enabler that made that a pleasant experience. At the heart of Qt is their signal-and-slot concept that makes it possible to tie components together without them needing to know about each other or their lifetimes. It’s implementation relies heavily on the C preprocessor.

Back in 2004 I decided to test D’s claim that a preprocessor is unnecessary to be equally powerful as C and C++. As a litmus test I made an attempt at implementing the signals and slots concept. I wasn’t quite successful [1]. Others tried as well, and I suppose that Walter got tired of the subject coming up on the mailing list time and again because one day he announced that he had implemented it himself and since then it has been in the standard library.

I have always thought that this was a good idea, and I still do: if signals and slots are standardised, GUI libraries and other frameworks can be built on top of that and then they will all be compatible. Somehow that hasn’t happened yet. Neither has std.signals been the last word on the subject, because both descore[2] and phobosx[3] provide alternative implementations. And if I’m not mistaken, dlangui[4], ironically, uses its own variant.

I understand that std.signal is not up to modern standards, and maybe deprecating it is a good idea. But I can’t help feeling that we thereby have failed to prove a point.

— Bastiaan.

[1] http://www.dsource.org/projects/dcouple/wiki
[2] https://code.dlang.org/packages/descore
[3] https://code.dlang.org/packages/phobosx
[4] https://code.dlang.org/packages/dlangui

April 12

On Tuesday, 30 March 2021 at 11:23:21 UTC, Berni44 wrote:

>

I've got the feeling, that std.signals is rarely used and not up to D's standards... Therefore I suggest to move it to undead and deprecate it.

But I might err on this. What do you think?

I meanwhile filed a PR. If you've got still any opinions on that, you might like to share them there.