3 ms·

Has the C++ standardization committee given a rationale why a module definition does not automatically also create a namespace with the same name? That would se

• adjav 3y ago
  According to cppreference (https://en.cppreference.com/w/cpp/compiler_support/20 https://en.cppreference.com/w/cpp/compiler_support/20), MSVC has everything implemented. GCC is close but its modules support remains lacking.
• halflings 3y ago
  > Has the C++ standardization committee given a rationale why a module definition does not automatically also create a namespace with the same name? That would seem such a useful feature. I'm not sure what the official rationale is, but I feel that would cause great namespace pollution. Some companies use one namespace per "logical" unit of code (e.g. a subproject), not for each small piece of code (e.g. a small module implementing a couple of classes.
  • mathstuf 3y ago
    I'm speculating, but I think that if one enforced "module is a namespace", projects like Qt, standard libraries, and other libraries would be forced to ignore them for far longer than anyone wants due to ABI stability requirements. If `#include <vector>` got you a different `std::vector` than `import std;`, I don't know how you would get everything that passes a vector over an API boundary ported without doing it all-at-once. Not to mention that if it were the case, things like a "Boost incubator" library would be in a separate top-level namespace as it could not "inject" itself into `import boost;`.
• humanrebar 3y ago
  Modules adoption would be severely stunted if everyone had to adjust all calling code in order to convert a library to use modules. Ideally one could find/replace includes with analogous imports, a bit at a time. I guess we could instead mandate that module names have to match the namespaces inside (i.e., mandate what modules are named up front), but it's also common to have C++ namespaces be reopened for various reasons (like adding to overload sets in supported ways). Anyway, bottom line is that modules and namespaces need to have M:N relationships, though in practice, it should be Bad Practice to get too creative there. Nobody has added namespace/module matching rules to CppCoreGuidelines or clang-tidy yet, but right now is a good time for some ideas in that space.
  • maccard 3y ago
    This is how every other language handles it, it's not new territory #import foo foo::bar(); vs #import foo::bar bar(); Now, I'm sure there's more nuance to actually standardise this, but given you already need to replace #include with #import, this isn't going to catch anyone off guard.
  • dureuill 3y ago
    > Modules adoption would be severely stunted if everyone had to adjust all calling code in order to convert a library to use modules. "We'd like this new feature to be good, but we have to cripple it for adoption/back-compatibility reasons". This is the entire story of C++, sadly :( Modules being orthogonal to namespaces means: 1. Bad Surprise for people first using modules, leading to incomprehension as this is different from every other language 2. Occasional Bad Surprises for people using modules even after the first time, as people will export stuff outside of namespaces/in the wrong namespace from time to time 3. Some code using the convention that the namespaces in modules follow the module "hierarchy" (which is also entirely a conventional concept because `.` is not treated as a special character) and some code not following that convention, either because it was hastily ported to modules or because the authors elected not to care for this particular convention. Now enjoy not knowing that when importing a module from a third-party library. Unfortunately the orthogonality to namespaces, in the name of "facilitating migration", cripples the language forever and actually reduces the motivation for migrating to modules (because it doesn't remove footguns). Doesn't help that the whole module feature is designed in this spirit. I'm lucky enough to have migrated to greener languages, but I don't think I would find it worth it to migrate to modules if I were still in the position of deciding what C++ features to introduce in my team. > Ideally one could find/replace includes with analogous imports, a bit at a time. Make a tool like `cargo --fix`, or something. Ah no, we can't, because of headers (and more generally the preprocessor), ironically :(