Ruben Perez via Boost
I don't see what's so difficult about this requirement. Just put your #includes above your imports, and don't use imports in header files. Header-based code will automatically follow these rules by virtue of not using imports. Module-based code will naturally follow these rules by virtue of not using header files, and by putting the #includes above the imports. Or am I missing something here?
What I understood (please correct me if I'm wrong) is that importing a module that uses an include in its global module fragment and then importing another module does violate this rule.
I tend to agree with Rainer, this would only become an issue if you start putting imports into headers (and only for modules that can also be consumed via headers). In particular, I believe this specific issue (ignoring declarations that have already been imported/included) is limited to a single translation unit. But maybe I am wrong. Can you elaborate on the scenario that you think is problematic? In particular, I think the "and then importing another module" part is missing the "that does XXX" (maybe "that uses an import instead")? I've tried the following with Clang 18 and libc++'s std module and everything seems to work without any issues: // a.mxx module; #include <iostream> export module a; export void a (std::ostream& os) {os << "a";} // b.mxx export module b; import std; export void b (std::ostream& os) {os << "b";} // c.mxx // export module c; import a; import b; import std; export void c (std::ostream& os) {a (os); b (os);} I've tried different orders of importation in c.mxx without any changes in the result.