I was going to say that the same applies to the -std level, but it occurs to me that in order to build and use modules, you need at least -std=c++20 anyway so most such issues won't manifest for now, until we get conditional uses of C++23 or C++26.
In the prototype I'm writing, it's C++23, since everything uses import std. As you have mentioned many times, that's the only way to cut build times.
We also have an interesting problem with -fno-exceptions; the function boost::throw_exception in that case is only declared on our side, but defined by the user. This (I think) means that the declaration can't be exported by the module, it needs to appear in the GMF. Maybe.
I haven't reached this yet, but my idea was to declare the function as extern "C++", which AFAIK attaches it to the global module, even if it's declared outside of it.
By the way, I posted about the optional `export` idea to the committee mailing list, and Michael Spencer replied and basically said "don't".
"My suggestion is to do either `export import
;` in the module if you are ok with getting extra declarations, or `export using ...` like libc++ does. Trying to textually include a header into the purview of a named module is fraught with issues." Since everything that's textually included becomes attached to the named module, it's too easy to create ODR violations.
But, apparently, Clang doesn't like header units, so the above is also not quite optimal.
I'd like to understand more about this, since this is the approach I
have been following (and AFAIK, the one that John Maddock and Matt
Borland followed, too). What would be the possible ODR violations
here? Does he refer to the case where we forget to #ifdef-out an
include for a dependency?
It looks like `export import
[1] https://clang.llvm.org/docs/StandardCPlusPlusModules.html#reduce-duplication... [2] https://anarthal.github.io/cppblog/modules2#template-spec [3] https://github.com/anarthal/cppblog/issues/1