[volta83]

> Don't want to end up with every C/C++ compiler being a clang skin in the same way as (almost) every browser is a chrome skin.

Why not ?

There is one open C++ spec, that's really hard to implement, so we have a dozen C++ compilers that are impossible to support properly because they each have their own set of different ten thousand bugs.

The value of supporting all of this is really small in practice, and the cost for everybody involved is huge.

Having a single, e.g., C++ parser with a single set of bugs is a much better value proposition for C++ programmers.

[account42]

We did have one major C++ compiler on Windows (MSVC) and one major C++ compiler elsewhere (GCC) and they both stagnated in many areas before Clang came along and forced them to advance to stay competitive.

[pjmlp]

GCC wasn't elsewhere.

Up to 2005 I was using UNIX own C++ compilers, meaning aCC, xlC, SunPRO.

Then there were Microchip, ARM, TI,...

[pumpkinpal]

There are real benefits to be gained though from new compilers. Look at "Circle" by Sean Baxter as an example. Outside of supporting a powerful form of compile time computation and allowing things such as reflection and writing shaders directly in C++, benchmarks have been floating around showing that it compiles quite a bit faster than GCC and Clang whilst still being able to compile big projects such as Boost. Although LLVM is the backend, the front-end is written from scratch by one guy.

https://www.circle-lang.org/

[lenkite]

Clang is lagging behind in C++ 20 support while MSVC is miles ahead. LLVM is also getting slower and slower every release.

[volta83]

So?

I don't see how focusing the available manpower on one implementation instead of splitting it over 10 different implementations would make this worse.

I do see how it would make this much better.

What one implementation lacks, another implementation provides. This is a weakness of the current ecosystem. Most software projects restrict themselves to the minimum common denominator, and splitting manpower across compilers lowers it.

[logicchains]

You sound like you haven't worked with many BigCo projects. Clang is turning into an "enterprise" junkyard due to too many cooks spoiling the broth, crumbling so much under the weight of its own complexity that 2022 is almost here and support for C++20 still isn't anywhere near complete (unlike GCC). The more parties that get involved, the worse the code will get. Clang already has more people working on it than MSVC, yet MSVC is iterating faster; this suggests a fundamental problem with the architecture or development processes of Clang, which is not something that will be fixed by more hands on deck (remember the mythical man-month).