I have questions regarding this - maybe you can help me here: * Let's say I build a Boost module. This #include's std headers in its global module fragment. * Now the user compiles their main.cpp, and they import boost and the std modules. No includes here. Is this scenario supposed to work? If it is, is it supposed to be portable (i.e. defined by the standard)?
It's *supposed* to work portably according to the Standard (N4971 [std.modules]).
With our current implementation, this is effectively the include/import mixing that's challenging for MSVC to handle. (May or may not work in VS 2022 17.10. I have a test that ensures that *plain* #include <meow> before import std; works, but not more exotic scenarios. Basically anything that leads to the std module being dragged in, and *then* the compiler seeing an #include <meow>, will result in the compiler seeing duplicate machinery that with the current implementation it cannot reconcile. Having #include <meow> be within another module's GMF counts AFAIK.) It would be better for the Boost module to be built on top of the Standard Library Module (both in terms of avoiding current compiler limitations, and for long-term cleanliness and build throughput).
STL
I see. Is it expected to be fixed in the near future? AFAIK libc++ makes it work by making the std modules a proxy to the standard headers, with the "export using" idiom. I know it'd be better for clean-ness in the long run, but this requires much more maintenance. I see it difficult right now to get enough buy in from library authors as to commit to #ifdef-ing out all their standard includes. If we managed to get a non-intrusive implementation out and this gained some traction, we could then think to do what you proposed. Ruben.