Deprecate std.signals

[berni44]

I've got the feeling, that std.signals is rarely used and not up to D's standards...

The discussion in the forum only revealed, that we might have failed to prove a point.

See also dlang/undeaD#45.

[dlang-bot]

Thanks for your pull request and interest in making D better, @berni44! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + phobos#7952"

[RazvanN7]

cc @atilaneves

[atilaneves]

What's wrong with it and what would be the alternative?

[berni44]

What's wrong with it and what would be the alternative?

I can't actually say, what's wrong, because I never used it. I remember that I tried to fix a bug about a year ago and gave up with the impression, that this module cannot be helped (but I do not remember details). Additionally from what I read in the forum and on other places, I think it was rather poor perceived by others too.

I believe that in a living library, all packages should be taken care of. From my perspective I'd say, that currently only few people care about working on Phobos at all, so lot's of packages are in an more or less orphaned state. To match the library with the available manpower, I think it would be wise to reduce it by some outdated modules. That would help us concentrate on the good things that Phobos has to provide.

Having said this, I'm not attached much to this PR - feels a little bit like garbage collection. :-)

Alternatives mentioned in the changelog:

• https://code.dlang.org/packages/descore
• https://code.dlang.org/packages/phobosx

In the forum there was also http://www.dsource.org/projects/dcouple/wiki and https://code.dlang.org/packages/dlangui mentioned.

[WalterBright]

fix a bug

I found the following bugzilla issues for std.signal:

9606  4150 16203 17011 18903 19842

If you're fixing a bug, make sure it is in bugzilla.

[berni44]

If you're fixing a bug, make sure it is in bugzilla.

I think it was one of the bugs in bugzilla, that I didn't manage to fix. I can't imagine, what else should have drawn my attention to fixing bugs in std.signal.

[berni44]

Having had time to ponder this, I think it is a module where no one cares - not even if it is removed or not: There was quite little interest, when I asked in the forum. Here the same, just @wilzbach giving a thumbs up at the beginning.

I had a look at its usage on github: Essentially 2 hits, the first one, RuladaEnglish, has not been touched since 2016. The second one doen't use std.signals directly, but used it to write it's one version.

From my point of view, I'd say std.signals is not used at all; it's just a maintenance burden (though admittedly not a large one, but still, if we decide to keep it, I think, the issues mentioned by walter should be taken care of sooner or later).

Don't know, how to continue here. I still believe, that it would be better for Phobos to remove it, but I don't really care (like all the others...).

[berni44]

I had a look at its usage on github: Essentially 2 hits, the first one, RuladaEnglish, has not been touched since 2016. The second one doen't use std.signals directly, but used it to write it's one version.

Huh, I wrote std.signal instead of std.signals... No wonder, that there are so few hits... its correct usage on github shows 380 hits. That's more, but still rather bottom end...

[berni44]

Meanwhile I went through all the 380 hits to see, how many are real hits (most of them are copies of Phobos). Complete list:

last update	project
2021	https://github.com/symmetryinvestments/autowrap (examples)
2021	https://github.com/mbierlee/retrograde
2021	https://github.com/lispysnake/serpent-demo-paddle
2021	https://github.com/lispysnake/serpent
2021	https://github.com/kirbyUK/dnes
2021	https://github.com/k3kaimu/carbon
2021	https://github.com/JustABanana/konsola_operatorska
2021	https://github.com/ahmetsait/imgraph
2020	https://github.com/XzoRit/coding_dojo
2020	https://github.com/Lansatac/ecs
2020	https://github.com/kagisogames/learning
2020	https://github.com/carblue/acos5_gui
2020	https://github.com/azbyn/sclid
2019	https://github.com/SeijiEmery/gsb
2019	https://github.com/Dvlv/fossproof
2018	https://github.com/Sepheus/Grollo-Engine
2018	https://github.com/micabressan/trabajo_final
2018	https://github.com/FeedBackDevs/feedback
2017	https://github.com/patrickjm/janus-editor (archieved)
2017	https://github.com/owlchain/owlchain-core
2017	https://github.com/nilsding/crash-game
2017	https://github.com/Heromyth/Iup4D
2016	https://github.com/ousttrue/dgl_sample
2016	https://github.com/marmy28/db_constraints
2016	https://github.com/jcd/deadcode
2016	https://github.com/Dechcaudron/puppeteer
2015	https://github.com/skilion/swizzle (first commit)
2015	https://github.com/D-Quick/DQuick
2014	https://github.com/yamadapc/bed
2013	https://github.com/todayman/d_template_experiments
2013	https://github.com/lycus/mci
2013	https://github.com/jniehus/vibed-qunit
2013	https://github.com/callumenator/glui
2010	https://github.com/kovrov/scrap
2009	https://github.com/weimingtom/iteration-zero

Looks, like a dozen or so projects actively use std.signals. Obviously public GitHub projects represent only a fraction of all projects so I estimate on a git level about 100 projects using it.

I also collected some comments about std.signals I found in the source code:

• "(std.signals is class based, but it's ugly-as-fuck and has to be implemented as a template mixin (wtf?!)). " (https://github.com/SeijiEmery/gsb/blob/1908340ff4af5507a75fe588c965a3e8f7df1740/gsb/src/utils/signals.d)
• "A very simple signal structure, to avoid having to use D's std.signals" (https://github.com/craigcabrey/grestful/blob/1226a90a65eb6bf278782be7ddfb47a43f9c1cbc/Generic/Signal.d)
• "Tends to crash when delegate bodies attempt to access the parent frame. std.signals exhibits the same problem." (https://github.com/JesseKPhillips/Juno-Windows-Class-Library/blob/bbbd9ced118365a9e05a4b73d8111ea775ff1ce9/source/juno/base/events.d)
• "Works with structs as opposed to the std.signals implementation." (https://github.com/hakkabon/d-properties/blob/bb758331a239903c8b295cd85bb5e5b0ce631f48/property.d)
• "// import std.signals; // outdated
  import util.signals; // new" (https://github.com/cairoD/cairoD/blob/2fbc89ea968d3286ad1c8ecc588093f43b8c0b22/examples/win32/window_framework/window_framework.d)
• "std.signals doesn't support emitting from emitted signal that also disconnects something unrelated. Weird... but work around it by delaying actual work a bit." (https://github.com/jcd/deadcode/blob/d96c877ecb7e0e5e1fcd5cefb9d55344923f3290/libdeadcode/src/application.d)

There were also 3 or 4 places, where the import of std.signals was commented out.

Hope, this helps somehow to find a decision.

[berni44]

New important post in forum

[atilaneves]

Right now I'm against deleting it for the sake of it. I could obviously change my mind if I heard a compelling argument though.

[RazvanN7]

New important post in forum

@berni44 That's an argument for closing this PR, right?