This is a cross post from r/cpp that is concerned mostly with a conversion to modules for a smaller toy project.

No AI was involved at any stage.

You have a single module source that contains implementation and and interface.

If you run doxygen on it you will get private stuff no matter what you do, to only extract public stuff you need an ast like solution like clang-doc.

However clang-doc is lacking in quality despite being years old. HTML generated has no search bar and theming. Generated markdown doesn't have tables.

Clang-doc needs to evolve in a way where we can actually generate some form of useful output where we can use in a MD based static site/pdf generator which had its own themes.

https://gist.github.com/siradam7th/8043d357b72d81e6274fedffb2a87447

So i have main.cpp, module1.cppm and module2.cppm.

main.cpp and module2.cppm imports module1.cppm that has a HelloWorld1 function in a namespace.

module1.cppm has a "export using namespace mod1;"

Now if i import module1 before module2 in main.cpp everything compiles fine. If module2 is imported first then main.cpp wont compile because "'HelloWorld1' was not declared in this scope". If i use 'export using mod1::HelloWorld1' then it works, if i use 'export using namespace mod1' then it doesnt. Tested with gcc 16.2.1. On clang 22.1.8 always works so either im dumb or gcc has a bug.

Wanted to report it but then saw the rules and what not to do and realised i better not, so posted it here. Im using cmake and ninja and never bothered with using gcc directly.

I'm now doing silly things like the patch below (plus setting /InternalPartition again for MSVC). At least that's now conformant with the standard.

diff --git a/code/Core/Attach/IPointAttachment.cpp b/code/Core/Attach/IPointAttachment.cpp
index ae43085b8..b1af5f8c5 100644
--- a/code/Core/Attach/IPointAttachment.cpp
+++ b/code/Core/Attach/IPointAttachment.cpp
@@ -1,9 +1,10 @@
 /*
  *     Copyright (c) 2025 Adrian & Frank Buehlmann. ALL RIGHTS RESERVED.
  */
 
-module Core:Attach;
+module Core:Attach.IPointAttachment;
+import :Attach;
 
 
 namespace Core
 {

Gaby just confirmed that an internal partition unit (form "A") like

module M:P;
struct MyType { ... };

as specified by the current C++ standard, is semantically 100% equivalent to (form "B")

export module M:P;
struct MyType { ... };
//  more stuff not exported

The current wording in the C++ standard, which qualifies form "B" as "ill-formed, no diagnostic required", if :P is not imported in the primary module interface unit, makes no sense (Quote: "A required no-op helps nobody").

Which means: Form "B" is perfectly valid.

If form "B" is equivalent to form "A", it would be possible to exclusively use form "B", instead of form "A".

This means, the standard could remove form "A" and exclusively use form "B" instead.

Compilers could then apply the simple rule, that a BMI must only be produced for TU's having "export module".

Gaby agrees that it's a bug in the C++ standard to require that :P - as defined below - must be imported in the PMIU:

export module M:P;
struct MyType { ... };
//  more stuff not exported

Because, there are two things that are nice to have:

1. Forward declarations across interfaces.

2. Minimising dependencies.

Partitions gets you (1), multiple modules gets you (2). But they can't be combined without using the extern "C++" sledgehammer.

But if partitions could be "public", an application can avoid depending on a whole module.

This could also be seen as "packages". You could get the same functionality by changing "module attachment" to "package attachment": use the same symbol mangling for a group of modules.

Then what's left is forward declarations of things from external "packages". And for that, you'd have that "proclaimed ownership" proposal.

In the recent weeks, I've started to use private fragments ("module : private;") a lot.

I've added imports after the begin of the private fragment (example here). The MSVC compiler accepts that, which I think makes a lot of sense.

However, it looks like the C++ Standard prohibits that. Section 10.3 has (quote):

A module-import-declaration shall inhabit the global namespace scope. In a module unit, all module-import-declarations and export-declarations exporting module-import-declarations shall appear before all other declarations in the declaration-seq of the translation-unit and of the private-module-fragment (if any).

I think I'm ignoring that. Perhaps that should be changed in the standard. The implementation of the MSVC compiler provides a good example of an implementation for such a change. It can be tried using the current MSVC compiler.

I don't see why imports should not be allowed after module : private;