For instance, last time I checked them out (in MSVC) it was perfectly fine to expose an un-exported type via an exported function. Apparently this is by design.
The problems that paper points out are certainly real, but:
- They're not specific to modules (the codegen dependency issue is there even right now)
- They're not specific to C++ (Java faces a similar problem)
- They all have solutions: either you have to tell the build system what the dependencies are directly, or your compiler has to be able to build the dependencies too. Bazel and gradle already handle these, just in a different context than C++20 modules.
So while C++20 modules are harder to use, and they very well might not get adopted, it's not really a design problem, nor an unsolved one - it's just a fundamental impedance mismatch that occurs in any language where the dependencies are specified in the same file that's being compiled.
i.e. It's a problem for the build system to solve, and ones do exist that have solved other forms of it in the past.
In Rust, such a thing is an error.
https://play.rust-lang.org/?version=stable&mode=debug&editio...