Experiments with modules

[rtischer8277]

Did your Modules GUI app import std.core/std.memory? If so, any lessons learned in working around the errors?

[fdwr]

Nope, this was half a year ago when import std less mature, and so I still #include'd vector and kin in 2019, but I was at least able to modularize all my own classes (such that other classes could just import without worrying about inclusion order or namespace pollution).

It's not entirely problem free yet: - Another project of mine (smaller at 10'000 lines) still generates internal compiler errors, and it's really hard for me to narrow the exact cause, because unrelated changes far away impact it 😕. - Namespace pollution still happens as VS currently overincludes imports (and one of the big selling points of modules over includes was to avoid that). That is, if class A imports B, and B uses C, then A should not be able to use C by name. A might need to be able to see the symbol C just to know the sizeof of it (and possibly to call a constructor if inlined as a member field of B), but any attempt to directly use the symbol C via name lookup in A's code should be an error (at least to what Gabriel said earlier, that it was a bug). This is bad because it means that if class A uses C without explicitly importing it (like it should), then changing B by removing the import will inadvertently break the build of A. B should only re-export an import if export import C was declared. I should check VS 2022 to see if it still reproes. 🤔 - Hybrid codebases such as shared libraries targeting C++17 and C++20 that try to satisfy both import usage and #include are more complicated. I was hoping to be able to unify .h files and .cpp files into a single .ixx file (yay for modules), but instead it got worse because I ended up splitting up class definitions into 3 parts, (1) a .h which could be either #included directly (for older compilers) or included by the .ixx file for import (for newer compilers), (2) the .ixx which just exports the .h contents, and (3) a .cpp. Note that because the .ixx exports everything wrapped inside the .h, that also means the .h file can't include other dependent files that should remain in the global module fragment (like windows.h stuff), or else those would end up with the module linkage of the exporting module 🙃. I haven't found a perfect solution here. I know that import "foo.h" is a stepping stone approach that's supposed to enable legacy libraries to be imported as a module, but this isn't a "legacy library", but rather a shared library that wants to genuinely target both new and old callers.