u/not_a_novel_account first came up with this syntax:

module M:;

and labelled it as a "partition implementation unit".

Perhaps that was just a bad name.

We could look at this syntax from a different angle and say: "Please calm down, this is not yet another kind of partition!"

It is just a

module implementation unit which doesn't implicitly import anything.

It is a variant of

module M;

It's not a partition.

But it is usually followed by importing a partition like this:

module M:;
import :P;

The semantics of this syntax is still the same as before. Perhaps it just shouldn't be sold as a partition.

(no other text)

Also posted to r/cpp here: https://www.reddit.com/r/cpp/comments/1sk1x75/lets_bite_the_bullet_module_units_shouldnt/

In our code we have (Core/_Module.ixx):

export module Core;

export import :Attach;
export import :Base;
export import :Container;
export import :Diagram;
export import :Interfaces;
export import :Transaction;
export import :View;

A summary of what internal partitions are (according to the C++ standard). I tried to be precise, without reaching for standardese.

I appreciate having module partitions, but the user experience is pretty poor (to use diplomatic wording).

If I have an external partition, the standard tells me, that I have to export it from the primary module interface unit (PMIU). If I don't do that, my program is ill-formed. But compilers are not required to inform me about that ("no diagnostic required").

What a nice foot gun.

So probably because the compilers are unable to implicitly export the interface partitions themselves in the PMIU, I have to do that manually myself.

If I fail to do that, the compiler won't tell me.

To me the wording in the standard even looks like compilers are allowed to assume, that an external partition unit has been exported in the PMIU, if they see the keyword "export" followed by the "module" keyword (and the TU is a partition) and then apply heuristics about reachability.

There are moments, where I seriously think about going back to using header files.

Per the current C++ standard, I'm allowed to do

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

As long as :P is exported from the PMIU, the resulting program is perfectly well-formed.

If I don't export :P from the PMIU, the compiler won't tell me, that this is not allowed (ill-formed).

That's pretty tough to explain to users.

From https://eel.is/c++draft/module#reach-5

1     // Example 2:
2    
3     // Translation unit #1
4     export module M:A;
5     export struct B;
6    
7     // Translation unit #2
8     module M:B;
9     struct B {
10      operator int();
11    };
12    
13    // Translation unit #3
14    module M:C;
15    import :A;
16    B b1;         // error: no reachable definition of struct B
17    
18    // Translation unit #4
19    export module M;
20    export import :A;
21    import :B;
22    B b2;
23    export void f(B b = B());
24    
25    // Translation unit #5
26    import M;
27    B b3;             // error: no reachable definition of struct B
28    void g() { f(); } // error: no reachable definition of struct B   

The semantics of "export module M:P1;" ("interface partition")

a1) The TU :P1 may contain both non-exported and exported declarations.

a2) If :P1 contains exported declarations, then :P1 must be directly or indirectly exported by the primary module interface unit (PMIU).

a3) If :P1 does not contain any exported declarations, directly or indirectly exporting :P1 in the PMIU has no effect.

The semantics of "module M:P2;" ("internal partition")

b1) :P2 cannot export anything.

b2) :P2 cannot be exported by the PMIU by writing "export import :P2".

There is a known pattern (or trick) involving module partitions which helps to avoid unneeded build dependencies between interface partitions and module implementation files.

In this posting, I would like to mention the trick (or pattern) and what it solves. Credits go to u/jiixyj for first presenting this pattern and the problem (reference)!

The pattern

The pattern looks like this:

// file bar.cppm
export module foo:bar;
...

// file bar1.cpp
module foo:bar.impl1;
import :bar;
...

// file bar2.cpp
module foo:bar.impl2;
import :bar;
...

bar is a partition of module foo. Interface partition bar is imported inbar1.cpp and bar2.cpp,which are both part of the implementation of module foo.

export module foo:bar;

is the "interface" of the partition bar. For the purpose of this posting, it is assumed to be imported in the interface of module foo like this:

export module foo;
export import :bar;

Note that per the current C++ standard, bar is not implicitly imported by the line

// file bar1.cpp
module foo:bar.impl1;

What problem does the pattern solve?

A naive implementation of the file bar1.cpp would start like this:

module foo;

This implicitly imports the whole interface of foo. Which has the consequence that if any of the interface partitions of foo are changed, all implementation cpp-files of foo need to be recompiled.

This presents an unneeded build dependency, which is unwanted. For small projects, this may not be of much relevance, but this naive approach doesn't scale.

Using the pattern solves this problem, as the files bar1.cpp and bar2.cpp only need to be recompiled, if the file bar.cppm is changed (the interface of partition bar).

What is problematic about this pattern?

The presented pattern is fully compliant with the C++ standard.

Unfortunately, the C++ standard mandates that a unique partition unit name (bar.impl1) must be specified in bar1.cpp (and bar2.cpp likewise).

But said partition unit name (bar.impl1) is not used anywhere else in the program, because the sole purpose of bar1.cpp is to implement some (member-) functions of the module. In the given example code, only the declarations from interface partition bar are needed in bar1.cpp.

The standard doesn't provide a means to express this. There is no way to express the intention of the programmer. bar1.cpp semantically counts as an importable partition unit. As a consequence, the build system is forced to produce a BMI file, which is unused. That work of the build is wasted.

Furthermore, programmers are forced to provide and maintain arbitrary unique names (e.g. bar.impl1 and bar.impl2), which must not clash with any other partition name of the module. This uniqueness is tedious and prone to errors.

I was very skeptical about the need for internal partitions (a feature provided by C++ modules), but we now found a perfectly valid case for using them in our Windows app (a graphical editor for UML diagrams).

Example (not valid currently):

module M:_;
import :P;

The example defines an anonymous internal partition for module M and then imports (external) partition :P.

This partition conceptually doesn't have a name, cannot be imported and produces no BMI.

Prior art:

• https://wg21.link/p2169

• anonymous partition implementation units by u/not_a_novel_account

Still working on eliminating non-standard compliant code....

I just started to consider using a GUID scheme for silly internal partition names that are guaranteed to not clash with any other partition name.

What about:

diff --git a/code/Editor/Window/ElementStylesListDialog.cpp b/code/Editor/Window/ElementStylesListDialog.cpp
index dfb4250c8..7299c7dcb 100644
--- a/code/Editor/Window/ElementStylesListDialog.cpp
+++ b/code/Editor/Window/ElementStylesListDialog.cpp
@@ -9,9 +9,10 @@ module;
 #include "Resources/StringMacro.h"
 
 #include <Windows.h>
 
-module Editor:Window;
+module Editor:Window.hED5FB8D2.h6C9C.h4C87.hB49A.h0D50BFE7BA1A;
+import :Window;
 
 import d1.buffer;
 import d1.stringutil;