I think I'm starting to slowly digest c++20 modules... it's basically pre-compiled headers done right + some language support for interface and implementation distinction.
pre c++20: logical component is a *header file* and bunch of *source files*.
post c++20: logical component is a *module interface file* and bunch of *module implementation files*.
pre: have to use an include guard to identify the *header files*, and name collisions cannot be diagnosed.
post: got a language level module name that compiler can diagnose, as there should be only one *module interface file*, identified by an export statement - two of those with the same name in a single translation unit is a conflict.
pre: no way to tell if a *header file* modification actually made a difference, changing a comment or white space can cause a massive recompilation chain reaction, as *header files* are just copied into the *source files*.
post: extra compilation step of *module interface file* allows the compiler to make a judgement about the nature of the modification, emitting a compiled interface file that other dependent modules use for compilation, instead of copying the text. This compiled interface does not change if you haven't actually meaningfully changed anything that is marked to be exported in the *module interface file*.
now what I don't get is what's going on with gcc's module mapper... why do you need an external server/file/program to map module names to files? Why don't just import the compiled interface file by name, and build up the dependency graph that way. My module files imports and depend on the compiled interface file of your module which depends on module interface file of your module... the module name to file name mapper seems like a whole lot of trouble for a minor convenience of having import and export declaration match exactly...
