It also even works for C, so C++ and C can be compatible here.

Include translation mostly solves the duplicate definition problem, although sometimes the compiler does need to type merge. It definitely is a big task to deploy header units in a large codebase, but it's significantly less effort than moving everything to named modules.

The huge difference is that PCH's are generally only allowed to exist once per TU and if anything changes the whole thing needs to be rebuilt, while header units form a DAG. Given well written headers, it's almost transparent to switch to header units.

There's more toolchain and build system work needed to make this generally available to people, but nobody seems interested in working on it.

Clang modules have been made to work with distributed build systems, but I'm not aware of any publicly available build systems that currently do. Although there seems to be some effort in GN: gn.issues.chromium.org/issues/42440... and chromium.googlesource.com/chromium/src....

Header units are new in C++20. They are a way to treat a header as a separate translation unit, and then import it into any other TU that uses it by converting `#include` to `import`. Clang has had clang modules which are nearly the same thing for ~10 years now, and some companies are using this.

The capitalization is the worst part here.

Well, you were likely playing on a 640×480 or 800×600 CRT, so it was better. It's a lot different on a 4k LCD.

Yeah, I have a room at the very end :(

What would your preferred API be here? C doesn't have non-trivial output iterators, so having non-bounded APIs is always going to be an issue, while in C++ it's a nice way to allocate the correct size without double formatting.

Would be better if you couldn't pass a UB on overflow iterator though.

`poison`

Thanks. I was searching for other LLVM/compiler people and saw it.

Not just the LLVM dragon, it's a ponified version of the LLVM dragon I had commissioned.