On Thursday, 11 January 2024 at 13:46:26 UTC, Hipreme wrote:

A a = A(50, 100); //Does the same as C++ {} syntax

VS:

//C++:
A a{50, 100};

a struct with 10+ members is not a good design!

On Thursday, 11 January 2024 at 13:07:52 UTC, deadalnix wrote:

Discussing new features is kind of the language equivalent of bikeshedding. I don't have anywhere near the skills needed to fix any of those issues, but I could vaguely form an opinion on whether I like new feature X.

I think everyone has their own explanation for why D isn't catching on as much as people would hope. These aren't my reasons, but I wouldn't be surprised if there are some people who are turned away by these issues.

But your list is very much in line with one of Walter's recent posts on the other thread where he mentions how much time he spends working on things that no one else is working on. Some of these issues are undoubtedly hard to fix and not many have the expertise to fix them. The response from those sympathetic to the fork might be something along the lines that the burden often falls on Walter because some contributors leave. Its a tricky organizational problem. It's hard to have high quality/standards with a lot of contributors.

On Thursday, 11 January 2024 at 14:34:57 UTC, jmh530 wrote:
Its a

This is an organizational issue, how to arrange manpower, time, and tasks?

On Thursday, 11 January 2024 at 13:29:30 UTC, zjh wrote:

We used to have something similar (but not exactly the same) as this via the leadership's vision documents: https://wiki.dlang.org/Vision_statements

It'd contain things like a wishlist of features, "champions needed" tasks, etc.

My favourite is the 2016H2 document, because of the Phobos wishlist:

    Eliminate Phobos dependency on GC (in other words, make GC opt out a viable and simple option).
    Review all Phobos modules for compatibility with ranges - std.zip, for example, was done before ranges and does not work with them
    Replace modules that are lacking in quality: json, xml
    Strengthen definition of ranges, possibly improve API
    New modules such as: containers, SI units, rational numbers, fixed-point numbers, big decimals, unit testing framework, benchmarking, linear algebra.
    Use -cov to improve code coverage of Phobos modules
    Make sure every function in Phobos has an example
    Make sure every function in Phobos has Params: and Returns: sections http://www.digitalmars.com/d/archives/digitalmars/D/Phobos_Documentation_-_call_to_action_258777.html
    Take inspiration from popular modules in other languages for adding modules to Phobos
    Improve green threads/fiber support
    Create a module that enables code to be run on GPUs
    Create the interface code to the C++ STL
    Review all of Phobos for @safe compatibility
    Remove dependency on autodecode from Phobos

(I wish I had a better skillset back then to try to help out :( )

Sadly these wishlists never really lead to much progress from what I remember, so they got semi-silently dropped.

On Thursday, 11 January 2024 at 13:07:52 UTC, deadalnix wrote:

Threads that are manually created can be attached by using

ThreadT thread_attachThis_tpl(ThreadT)();

On Thursday, 11 January 2024 at 14:54:47 UTC, IGotD- wrote:

Should be:

Thread thread_attachThis();

On Thursday, 11 January 2024 at 14:51:21 UTC, Bradley Chatha wrote:

    Eliminate Phobos dependency on GC (in other words, make GC opt out a viable and simple option).
    Review all Phobos modules for compatibility with ranges - std.zip, for example, was done before ranges and does not work with them
   ...

The D leadership should refine these visions instead of focusing on specific details!

Specific details can be discussed separately,

But shouldn't the D leadership be more important in distributing tasks and refining the vision?

D leadership, although can focus on specific technical aspects, what is more important is to refine the tasks, refine the vision, and then delegate the tasks to the corresponding personnel!

Instead of focusing too much on technology

The D leadership should focus on explaining the structure of the 'DMD' code, making it easier for others to modify, distributing tasks, refining tasks, and supervising tasks while addressing technical difficulties.

On Thursday, 11 January 2024 at 15:45:55 UTC, zjh wrote:

Task List+Implementation+Schedule!
Just like engineering management, all D need is a task schedule.

On Thursday, 11 January 2024 at 14:47:16 UTC, zjh wrote:

Not so much. It's an ownership issue. You have to tell someone that they get to choose how to do the work. If it meets certain criteria, such as passing a set of tests specified in advance, it gets merged.

Very few people are willing to spend hours of their free time doing work, only to have it rejected because it's not the way the person in charge would have done it. I sure wouldn't. Especially considering that the criteria for rejection are arbitrary and revealed only after the fact.

If the folks at the very top of the organization want to maintain ownership of everything, the only work that gets done is the work they do.