@gracicot I can't get it to work. I have a source file including iostream and importing a module. The module imports Std and uses some stl stuff, e.g. a unique_ptr. And voila, I get redifinition errors in <memory>.
Without the include of <iostream> everything works as expected. And it doesn't matter If include or import comes first.
After watching C++20 Modules: The Packaging and Binary Redistribution Story by Luis Caro Campo, I'm even more convinced that #cpp#modules are a mistake. IMHO they just add more complexity that c++, SREs and build tool developers need to deal with, plus solve no real problem, but preprocessor definition conflicts for some legacy headers 🤷♂️
I know these are early days for this feature, and I really wish to be wrong here, but I doubt if this feature gets a wide adoption from the community (at least in it's current form)
@minoru Yeah, it gets really broken, when one wants to build different variants for a single module (architecture, optimisations, sanitisers, etc.) or apply some custom build qualifiers like Curl with http/2 protocol support only.
What we need (I guess) is some sort of intermediate pre-binary form that would account for the use cases above and cover template meta-programming too :)
Instead, we got BMI - kind of replacement for the header files, which still has to be be accompanied by .{a,so,dylib} files, and which can be implemented differently by every compiler vendor and even incompatible between different compiler versions 😂
@rttf@minoru The BMI is not a replacement for a header file. Module interface units are. You cannot even ship the BMI without the source with some implementation.
Modules don't enable full binary distribution and never attempt to fix that. You still have to ship your interface source, but now it's a .ixx instead of .hpp.