I've been using the GCC 15 alpha with -std=C++32 options, which has been interesting. All the new borrow checking features and even support for fully dynamically typed programs, but it's the garbage collection that is really an enjoyable step into the future. Also glad to see C++ finally ditch inheritance and go all-in on interfaces and protocols, it's about time.
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.
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.
11 comments
[ 4.4 ms ] story [ 29.1 ms ] threadSorry if I am too salty here, but really, it's more of a joke at this point, isn't it?
- 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...