1. Doesn't the D compiler contain an entire C compiler? Half the point of that section was to say that any C parser is halfway to being a fully functional compiler. That's arguably an exaggeration, but I fail to see how D serves as a counterexample.

2. How does the D compiler handle GCC- and Clang-specific extensions to C?

1. Yes, it does, but only the cparse.d file is for C. The rest of the "C" compiler hijacks the D semantic routines, code generator, and optimizer. There's also some custom work to turn #define's into simple declarations. If you just want to parse C, yes, you can just use cparse.d.

It's important to note that C cannot be fully parsed without keeping a symbol table, and cparse.d handles that, too.

2. C extensions will always be a problem. ImportC supports the most widely used ones. (Most C extensions are rarely used and can be ignored.)

C++ did this, what, 40 years ago? Then V, Zig, now D. I agree, in ten years most compilers and even interpreters will do it.

C++ did it the other way around. It added C++ to a C compiler.

But it didn't. In very few cases was a C compiler extended to compile C++. Instead, a C++ compiler just has to know how to compile C, and to link with C objects compiled separately.

But it did. I wrote the first native C++ compiler, by extending the Zortech C compiler.

That does not contradict my statement.

That's a less correct description than what Walter gave