Good afternoon,
is everything okay with the development? For example, https://code.dlang.org/packages/libasync. Only two years have passed, but this package is no longer being assembled.
Is it good?
In other words, it is still difficult to recommend D for use.
How sad it is...

On Tuesday, 19 July 2022 at 09:18:12 UTC, GL wrote:

Yes

You should ask the developers of the package. There should be a link to the repo at the link you posted.

That escalated quickly

On Tuesday, 19 July 2022 at 11:52:53 UTC, bachmeier wrote:

I wish I could be so sure. This means that most of the packages in "dlang.org/packages" are useless. "Libasync" mentioned earlier has over 15,000 lines, what a great job! And it's practically all rubbish. Only because someone decided that the enforceEx symbol previously defined in the STANDARD library was not elegant enough. In the standard, core library, Carl!
Something is rotten in the state of Denmark...

It is known, many repositories (such as the Linux package repositories) are known to use a mechanism for automatic rebuilding in a clean environment and notification, such as "repocop / hasher".
Is there anything similar here?
How does the author know that there are problems (how many authors read reports on packages published many years ago)?

On Wednesday, 20 July 2022 at 05:56:52 UTC, GL wrote:

You are talking about a third-party package. Do you contact the Rust core team with issues about arbitrary packages written in Rust? Do you tell them that Rust is a lost cause because someone wrote a package that's not properly maintained using their language?

I will repeat my earlier comment: Contact the developers of the package. For your convenience, this is the link

https://github.com/etcimon/libasync

On Wednesday, 20 July 2022 at 05:56:52 UTC, GL wrote:

I don't know anything about this library, but any library that has not reached v1.0 yet should be considered as experimental and unsupported…

On Tuesday, 19 July 2022 at 09:18:12 UTC, GL wrote:

Maybe the author just need help in development from community? Many libraries like libasync and memutils are used as dependencies in other projects.

On Wednesday, 20 July 2022 at 16:16:43 UTC, Ola Fosheim Grøstad wrote:

Version number? Yah?
In other words, when working in D, it is impossible to rely on any (open) code.

Or you need constant assistance from the authors, which is not realistic.

Or you have to constantly reinvent your own bicycles and substitute crutches. Tertium non datur. No "batteries included": it is simply impossible to rely on the development of useful code by the community, the obsolescence of the compiler requires constant and continuous rewriting of the "whole World".

PS: It looks like the author of the mentioned library is not responding or has lost interest. Assembly with a modern compiler requires a very deep analysis of the code, since cast errors occur. So, long live for own "bicycles and crutches". Wonderful.

On Wednesday, 20 July 2022 at 05:56:52 UTC, GL wrote:

actually, i find this a good idea. Packages are getting registered on code.dlang.org without any qualification (AFAIK). Maybe it would make sense to develop some automated challenge that a package/project must pass in order to get listed on code.dlang.org and after that periodical checks with a grace time after which the project will be flagged as unmaintained and eventually removed (or hidden by default with opt-in to see and use unmaintained packages)

On Tuesday, 19 July 2022 at 09:18:12 UTC, GL wrote:

hottake: its possible to use d without dub