You can get what you need done and working in C++. The trouble is, it's harder to do and the result just doesn't look that nice. A simple example:

C++:

    typedef struct S { int x; } S;

D:

    struct S { int x; }

There are a lot of things like that, and it adds up.

I have never even once encountered any problem caused by the tag namespace.

I never, ever, typedef struct tag names. I have only ever seen typedefs like that in C headers. All C++ code I ever see looks like your D example.

I have to wonder if you meant to post something else, or if you have lost touch with what C++ code looks like.

I use the typedef version to head off problems. Anyhow, how about this:

C++:

    template<class T> T func(T t) { ... }

D:

    T func(T)(T t) { ... }

or

C++:

    void f(long);

    void test() {
        f(1); // calls f(long)
    }

    void f(int);

D:

    void f(long);

    void test() {
        f(1); // calls f(int)
    }

    void f(int);

or

C++:

    int f(int a[3]) { return a[4]; } // undefined behavior

D:

    int f(int[3] a) { return a[4]; } // index out of bounds error

Of course, you can use `array<int>` in C++, and all the above can be worked around, but it just is more work and doesn't look as good.

C++20:

  template <typename T> T func(T t) { return t; }
  auto func(auto t) { return t; }  // same, "abbreviated"

C++ is often not as nice to type as D, or as Rust. That's backward compatibility for you. But having literally tens of billions of lines of code in production, and millions of programmers who know how to use it, counts for a lot.

Your example here is C style though.

struct S { int x; };

is perfectly valid C++

Yeah, but that enables you to declare another variable named `S` and it'll compile. The tag name space is still there, and still causes problems. The typedef approach ensures you won't have problems.

People have learned to deal with the quirky behavior of the tag name space, but it's still quirky and serves no purpose.

I wrote Bjarne back in the 1980s that the tag name space should be removed from `class` as that wasn't necessary for backwards compatibility with C. He replied no as it would have broken compatibility with existing C++ code.

I see it less dramatically: like C# is Java with the benefit of hindsight, D is C++ with the benefit of hindsight. No need of compatibility with early bad decisions and undesirable features is an unexciting but important feature.

C++ will structurally never have a borrow checker, because it's simply not designed in a way for that to be possible.

Correct.

But a borrow checker does not change the set of possible programs. It only identifies the subset of possible programs that would need "unsafe" blocks.

In the absence of a borrow checker, libraries are left to carry the responsibility to define an API that is hard to misuse. Such an API could be slower than what one would define for a library to be used under a borrow checker. But code written to satisfy a borrow checker is sometimes slower than code that doesn't need to.

>But a borrow checker does not change the set of possible programs.

Once you have Turing completeness you have the full set of possible programs, end of story. Languages aren't about changing the set of possible programs, they're about making good ones easier to write, and bad ones harder.

Then there is nothing but ones and zeroes, and nothing to compare, and no insight to be had.

Yet, C++, D, and Rust are much more like one another than any of them is like any other language. Your Turing Completeness tells you less than nothing about any important distinction between them.

D has a prototype borrow checker now. I'll be talking about it at the April NWCPP meeting.

I wouldn't characterize JavaScript's surprise fortune as miraculous.

Miracles are Heaven sent, right? What does Hell send? Maledictions? https://www.powerthesaurus.org/miracle/antonyms

Nobody knows how to get a programming-language miracle.

Sun committed a billion dollars to promoting Java—and the opportunity-cost loss is probably a big part of what killed them. It still would not have been enough to secure a place for Java, except that Java offered MS sharecroppers a road to a sort of freedom. Ada got even more $promotion than Java, in its day, but faded.

C got its miracle on the coattails of Unix, C++ on C's. Javascript rode on Netscape. (Who remembers MS Silverlight? MS spent as much as Sun.)

Python, if does survive, got its miracle the hard way. Perl and Ruby once seemed more secure than Python does now. Rust and Julia are going the hard route.

All it takes to fade away is not getting that miracle, mo maledictions needed.