[Sebb767]

> That probably works with C but it'd make C incompatible with C++.

C is not a subset of C++. The simplest example:

> int new = 1;

Perfectly valid C, but not valid C++.

Now, modules would obviously be a bigger break than a few keyword incompatibilies, but at that point you'd also massively increase complexity and basically start creating C++ again, which is probably the actual reason it hasn't happened yet.

[trealira]

Modula-2 had modules in 1978, and it was still a pretty simple language. They don't necessarily imply recreating C++.

[Gibbon1]

If you listen to the C++ people it's obvious they think the incompatible changes are a terrible mistake. They can't undo them but they're adamant no other breaking changes be allowed. They don't want things to get worse for them. Meaning better for everyone else.

And no modules wouldn't make C more like C++. It's just make C a bit saner and faster to compile. Because modules are complete and don't depend on code compiled before the import. Which means you can compile your modules exactly once and only once. Well written C code bases you could probably just change #include to #import and reap the benefits.

[flohofwoe]

TBF, C doesn't suffer from the "headers cause slow builds" problem of C++, because C headers usually only contain a handful of declarations (e.g. the C stdlib headers are a couple of hundred lines of function prototypes and struct declarations, not tens of thousands of lines of gnarly template code like C++ stdlib headers).

[Gibbon1]

When I've looked at what's going on with gcc what I see is most of the code being compile is header files. It's probably 90% headers and 10% actual code. And then there is all the dependency files it's reading. Though to be fair I think a lot of that is not so much trying to make C compile fast but to make C++ compile fast.