[Yotsugi]

I don't undestand why there's still no solution for this in STL. Surely compilers like GCC could support a setup where STL instantiations are cached somewhere? If it was just one extra compile flag telling compiler to cache all template instantiations in some directory however it pleases, that would solve more than STL problems.

[mattnewport]

Modules, standardised in C++20, are the official solution both for the standard library and for other code but they are not universally well supported by all major compilers and build systems yet.

Transitioning existing code to use modules is also not entirely straightforward, though probably no more problematic than introducing unity builds.

[forrestthewoods]

> though probably no more problematic than introducing unity builds.

A "Unity build" really just means typing #include "foo.cpp" a few times. It's trivial.

Meanwhile, neither Clang nor GCC support standard library modules. They have only partial support for modules themselves. C++ module support is non-existent in almost all build systems. https://en.cppreference.com/w/cpp/compiler_support

The idea of C++ modules is great. It's badly needed. In practice I'm not sure if they're ever going to be genuinely functional and widespread. Which makes me sad. Toy projects don't count.

[mathstuf]

It's been a lot of chicken-and-egg, but C++ modules finally have momentum. FWIW, Clang does support `import std` with `libc++` now. While I've implemented CMake support for modules, I've worked on laying the groundwork for compilers to be able to provide the required information (P1689) and I've been involved in advocating support from a number of build systems (e.g., Bazel, xmake, Meson, Tup). Some have been more receptive and made progress; others have had less.

Yes, it's very late, but progress is being made.