Date: Wed, 14 Jan 2026 00:08:44 -0800
On Sun, Jan 4, 2026 at 11:11 PM Chuanqi Xu via Core <core_at_[hidden]>
wrote:
> Hi Experts,
>
> The motivation of the mail comes from
> https://www.reddit.com/r/cpp/comments/1pzbnzy/comment/nww0aaw/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button (I’ll
> redescribe this if you are not interested enough).
>
> CMake didn’t allow users to not list module implementation partition
> units out of CXX_MODULES_FILES, which will generate BMIs. CMake
> developers said, this is required by the standard. Since the spec says, the
> module implementation partition units are importable. But I don’t think so.
> I think “can” be imported doesn’t mean it “must" be imported.
>
> But CMake developers said this is a standard bug. So I want
> clarification from the wording group and SG15 group (as this relates to
> build systems), is this a wording bug? If yes, do we want a paper for it or
> a defect report? What’s the suggested wording?
>
> —
>
> # Background
>
> I described the full background in my blog:
> https://chuanqixu9.github.io/c++/2025/12/30/C++20-Modules-Best-Practices.en.html#use-module-implementation-partition-units-not-module-implementation-units-to-implement-interfaces
>
> The story is, the module implementation unit will import the primary
> module interface implicitly. And all the module interface partition unit
> requries to be exported by the primary module interface. ([module.unit]p3).
> Then it implies that, if we change any interface units, all the module
> implementation units will be rebuilt. This is unacceptable in practice.
> e.g., internally for a module, we may have hundreds of implementation
> files. Then if we use module implementation units for all of them. The
> recompilation problem is unacceptable.
>
> But I got the solution. It is, use module implementation partition units
> to implement things. Then every thing solved. But cmake didn’t allow users
> to treat module implementation partition units as non-module srcs (
> https://gitlab.kitware.com/cmake/cmake/-/issues/27048). So users have to
> suffer from additional serializing cost. Then it is the beginning of the
> mail. The end users have the ability to design and know which units won’t
> be imported.
>
> Thanks,
> Chuanqi
>
The standard just says that implementation partitions can be imported, not
that they must be. The original design of implementation partitions is to
be the equivalent of header files that appear next to .cpp files, rather
than in the include directory, but I don't think it's terrible to use them
this way. I do still think the naming we have is quite confusing to people,
but the semantics largely make sense.
- Michael Spencer
wrote:
> Hi Experts,
>
> The motivation of the mail comes from
> https://www.reddit.com/r/cpp/comments/1pzbnzy/comment/nww0aaw/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button (I’ll
> redescribe this if you are not interested enough).
>
> CMake didn’t allow users to not list module implementation partition
> units out of CXX_MODULES_FILES, which will generate BMIs. CMake
> developers said, this is required by the standard. Since the spec says, the
> module implementation partition units are importable. But I don’t think so.
> I think “can” be imported doesn’t mean it “must" be imported.
>
> But CMake developers said this is a standard bug. So I want
> clarification from the wording group and SG15 group (as this relates to
> build systems), is this a wording bug? If yes, do we want a paper for it or
> a defect report? What’s the suggested wording?
>
> —
>
> # Background
>
> I described the full background in my blog:
> https://chuanqixu9.github.io/c++/2025/12/30/C++20-Modules-Best-Practices.en.html#use-module-implementation-partition-units-not-module-implementation-units-to-implement-interfaces
>
> The story is, the module implementation unit will import the primary
> module interface implicitly. And all the module interface partition unit
> requries to be exported by the primary module interface. ([module.unit]p3).
> Then it implies that, if we change any interface units, all the module
> implementation units will be rebuilt. This is unacceptable in practice.
> e.g., internally for a module, we may have hundreds of implementation
> files. Then if we use module implementation units for all of them. The
> recompilation problem is unacceptable.
>
> But I got the solution. It is, use module implementation partition units
> to implement things. Then every thing solved. But cmake didn’t allow users
> to treat module implementation partition units as non-module srcs (
> https://gitlab.kitware.com/cmake/cmake/-/issues/27048). So users have to
> suffer from additional serializing cost. Then it is the beginning of the
> mail. The end users have the ability to design and know which units won’t
> be imported.
>
> Thanks,
> Chuanqi
>
The standard just says that implementation partitions can be imported, not
that they must be. The original design of implementation partitions is to
be the equivalent of header files that appear next to .cpp files, rather
than in the include directory, but I don't think it's terrible to use them
this way. I do still think the naming we have is quite confusing to people,
but the semantics largely make sense.
- Michael Spencer
Received on 2026-01-14 08:09:08
