[DLoupe]

For me, D failed to replace C++ because of lack of design. It is more a mix of great features. But once you start learning the details simple things can get very complicated.

For example, function arguments can be "in", "out", "inout", "ref", "scope", "return ref" - and combinations.

Another example is conditional compilation. Great when used sparely, but can otherwise make it very difficult to understand how the code flows.

In the end, reading the source code of the standard library convinced me against it.

(The source code for the C++ standard library is much worse, of course).

[sfpotter]

I think it's a great mix of features. I agree it would make sense to separate the wheat from the chaff, but if you're a mature adult, you should be able to decide which features are useful to you and figure a dialect that works.

In general, the design of the standard library is much less alien and baroque than the STL, and is more battries-included, so you spend much less time puzzling over incantations and more time writing code. The code you have at the end is also much more concise and readable.

Likewise, because D is in a lot of ways "C++ with fewer problems and papercuts", I spend way less time figuring out totally inscrutable C++ compilation errors.

Consequently, I can spend more of time writing code and thinking about how to use all D's nice features to better effect. Plus, given how fungible and malleable the language is, it doesn't take a lot of effort to rework things if I want to change them in the future.

Personally, I think this is the main reason D hasn't caught on. It's selling point is that it's pragmatic and doesn't shove a lot of dogma or ideology down your throat. This isn't sexy and there's nothing to latch onto. There are many styles you can write D code in... MANY more than C++: Python-style, C#-style, C++-style, C-style... hell, bash style, MATLAB-style, R style, whatever you want. But for some of these styles, you have to build the tools! The fact that all of this is possible is the result of combining one very practical and ergonomic programming language, with a thousand different QOL improvements and handy tools... plus top tier metaprogramming.

IMO, the major thing holding D back right now is also along the same lines. It offers pragmatism and practicality, but the tooling is still weak. Languages like C++, Rust, and Python totally outclass D when it comes to tooling... but you have to sacrifice flexibility and ergonomics for baroque madness (C++) or BDSM (Rust) or slow and impossible to maintain code (Python). The choice is yours, I guess!

[troupo]

> For example, function arguments can be "in", "out", "inout", "ref", "scope", "return ref" - and combinations.

Reminds me of "In case you forgot, Swift has 217 keywords now" https://x.com/jacobtechtavern/status/1841251621004538183

[WalterBright]

> function arguments can be "in", "out", "inout", "ref", "scope", "return ref" - and combinations.

None of them are required. What they do is provide enforcement of semantics that otherwise would have to be put in the documentation. And, as we all know, function documentation is always either missing, outdated or just plain wrong.

For a (trivial) example:

    void foo(int* p) { *p = 3; }

vs:

    void foo(out int i) { i = 3; }

In the latter, you know that `i` is being initialized by the function. In the former, you'll have to rely on the non-existent documentation, or will have to read/understand the foo()'s internals.

`out` definitely is a win. Let's look at `scope`:

    void foo(int* p) { static int* pg = p; }
    void bar(*) {
        int x;
        foo(&x); // oops
    }

vs: void foo(scope int* p) { static int* pg = p; } // compiler flags error

This is most definitely a memory safety feature.

[senkora]

In general, you shouldn’t judge a language by the complexity of its standard library implementation unless you are planning to implement a comparable library.

Application code often only needs a subset of the language and can be much more readable.

The standard library needs to use every trick available to make itself expressive, reusable, backwards-compatible, and easy-to-use for callers. But for your application code you certainly want to make different tradeoffs.

[WalterBright]

> The source code for the C++ standard library is much worse, of course

But you prefer C++?

(The D standard library is in the process of being re-engineered for clarity, but still, it is far more comprehensible than C++'s.)

[DLoupe]

Thanks so much for replying, Walter. I'll give it another try.