Thanks clang lagging behind ISO C++, you can use them today on Visual Studio 2022.
Modules are unimplementable shite. They would be great if this was the first iteration of the language, but they're a nightmare to fit into the existing ecosystem. If they get support in open source compilers, we can look forward to at least one or two decades of a mixed modules/headers mess in open source projects.
If they were unimplementable, there wouldn't exist already two major C++ compilers supporting them to some degree.
It is only clang with their module maps pseudo concept that keeps lagging, that and plenty of other C++20 features.
Edit: Also, module support better be 100% binary compatible between GCC and Clang, or it's worse than complete garbage.
edit: to elaborate both g++ and clang++ implement the Itanium C++ ABI[1]. You might get binary incompatibility by mixing standard libraries, so just don't do that.
Additionally the C++ ABI doesn't tell anything about how each binary library was compiled regarding compiler and linker switches that affect runtime behaviour.
Right. This has nothing to do to gcc, clang and even C++ though. I would be surprised if you could freely link C shared objects linked to different libc implementations.
On most Linux distros both gcc and clang link to libstdc++, so everything works out of the box. I imagine this is not the case for MacOS xcode and gcc from homebrew.
(Like, literally, going by the size of the language spec.)
- they allow `.` in their names to signify hierarchy, but have no built-in notion of hierarchy or submodule. This means possible error messages will have to be suboptimal
- they are orthogonal to namespaces, meaning if you have a module `foo.bar` any identifier it will export will be in the global namespace unless you put it in the `foo::bar` namespace in the `foo.bar` module file. As a user this means that I can import a `foo.bar` module and expect symbols to be imported in any namespace.
- btw, what happens if different modules import the same name? I'll let you guess:-D. Modules were the chance to eliminate this kind of issues by eliminating the notion of shared namespaces, but oh well...
- modules have interface units, implementation units, partitions, interface partition and implementation partition. There must be exactly one non partition interface unit, called the primary module interface. Instead of, you know, just having modules and submodules files like all modern module systems in existence.
- Modules add new and fun ways to get ill-formed, no diagnostic required programs. Such as not re-exporting all interface partitions.
I really hoped that modules were the chance of introducing a simpler compilation model for C++. I'm not pleased with the result.
Some references:
[0]: https://vector-of-bool.github.io/2019/01/27/modules-doa.html
[1]: https://vector-of-bool.github.io/2019/03/10/modules-1.html
Same in Rust, the overwhelming majority of modules I create is in the standard filesystem <-> modules mapping. For generated code, I use the special syntax that allows not respecting this mapping, but that's once in a blue moon.
IMO, C++ should have taken the same steps: providing sane, correct and easy defaults, while allowing the flexibility to override them when necessary (with special annotations).
I'm disappointed that a modern C++ feature was designed in the long tradition of having bad defaults instead.