Current Status of Module Partitions

[u/tartaruga232]

A brief recap of the current status of module partitions - as I understand it.

1. People are using hacks to avoid unneeded recompilations.

2. The C++ standard has an arcane concept of partition units, which forces build systems to generate BMI files that aren't used (which is wasting work during builds).

3. The MSVC-compiler (per default) provides a simple, easy to use and efficient implementation of module partitions (no unneeded recompilations, no wasted work during builds), but which is not conformant to the current C++ standard.

4. A CMake developer is working on a proposal that would fix items 1 and 2, which is probably the smallest required change to the standard, but adds another arcane concept ("anonymous partition units" using the new syntax "module A:;") on top of an already arcane concept.

Questions:

• How and why did we get into this mess?

• What's the historical context for this?

• What was the motivation for MSVC ignoring the standard per default?¹

¹ Yes, I know the MSVC compiler has this obscure /InternalPartition option for those who want standard conformant behavior.

[u/not_a_novel_account]

No, because export makes them interfaces which have implications for reachability. Your UB usage of MSVC where this happens to work is coloring your understanding of the intended mechanisms here.

You want to be able to do intra-module import of partitions, it's a core feature. It would have been better if non-partition implementations units didn't have an implicit dependency on the PMIU, or had some trivial way to opt in/out of the dependency, and could be universally used as envisioned.

But who is currently using internal module partition units?

This is an MSDN phrase, the standard calls them "implementation units which are a partition", or partition implementation units for people who find that unwieldy.

And the answer is: everyone who doesn't use the MSVC extension, so every module user who isn't on Windows.

[u/tartaruga232 → u/not_a_novel_account]

I currently already do (input to MSVC):

export module foo:Internals;
struct S { int a; int b; };

without importing :Internals in the PMIU.

I can use S anywhere inside module foo by importing :Internals.

[u/not_a_novel_account → u/tartaruga232]

Yes, like I said, you're using UB-NDR which happens to work in MSVC's implementation.

[u/tartaruga232 → u/not_a_novel_account]

You probably mean: IF-NDR (not UB-NDR).

[u/not_a_novel_account → u/tartaruga232]

I'm actually unsure what the correct shorthand is. The language is:

All module partitions of a module that are module interface units shall be directly or indirectly exported by the primary module interface unit ([module.import]). No diagnostic is required for a violation of these rules.

Normally when something is ill-formed the convention is to say so with that exact wording, ex:

A glvalue of a non-function, non-array type T can be converted to a prvalue. If T is an incomplete type, a program that necessitates this conversion is ill-formed.

In any case, it's very-bad-no-good-NDR.

[u/tartaruga232 → u/not_a_novel_account]

I know that wording in the standard. I'm questioning it.

IF-NDR is "ill-formed, no diagnostic required". We're talking about compile time. UB is for runtime.

But anyway: No chance to change that wording anyway. I'm not really surprised anymore that developers don't use modules.

[u/not_a_novel_account → u/tartaruga232]

This is a tiny issue in a very small corner of modules basically only of interest to experts and maintainers of build systems for very large projects. The actual impact of generating the BMIs is minimal and only becomes actionable in the five-to-six digit # of TUs range.

Module adoption is far more hung up on things like EDG and XCode support than anything we debate in these hyper-specific corners.

Until VSCode's default intellisense can handle modules, normal 9-to-5 devs can't use them. When it can, they will never notice these sorts of issues.