3 ms·

I wonder when support for modules lands so we can see that the design doesn't work out and deprecate them. Sorry if I am too salty here, but really, it's more

I wonder when support for modules lands so we can see that the design doesn't work out and deprecate them. Sorry if I am too salty here, but really, it's more of a joke at this point, isn't it?

dataflow 3y ago
What's wrong with their design?
- 112233 3y ago
  https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1300r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p13...
  - dataflow 3y ago
    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.
- w4rh4wk5 3y ago
  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. In Rust, such a thing is an error. https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=16a67062304ba6856b9a924a75ea96d1 https://play.rust-lang.org/?version=stable&mode=debug&editio...
pjmlp 3y ago
Visual C++