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.