[Jason]

  * It seems to me that what you want is a module implementation unit that doesn't import the primary module interface unit.

Exactly!


  * This is not inherently a partition; you're just using a partition because that's the only way to avoid importing the PMIU. Giving this TU a throwaway partition name that will never be used elsewhere, that only serves to prevent the implicit import, is the first kludge I was referring to.

Hmm, it has the partition semantics in the sense that the declaration there are still attached to the same module. That is important, especially with “strong ownership” (which is now accepted as the only practical implementation strategy).


  * I don't see anyone saying that.

+1.

-- Gaby

From: Core <core-bounces_at_[hidden]pp.org> On Behalf Of Jason Merrill via Core
Sent: Wednesday, January 14, 2026 7:28 PM
To: sg15_at_[hidden]
Cc: Jason Merrill <jason_at_[hidden]>; core <core_at_[hidden]socpp.org>; Chuanqi Xu <chuanqi.xcq_at_[hidden]>
Subject: Re: [isocpp-core] [isocpp-sg15] [modules] wordings to allow build system to not always emit BMI for implementation partition units

On Thu, Jan 15, 2026 at 10:36 AM Chuanqi Xu via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>> wrote:
The discussion seems split into 3 parts:

- The standard wording
- If the proposed practice is good
- How build system (specially cmake) can support it

Terminology is not one of them. I used the term module implementation partition unit. The term is not defined in standard wording. Use the standard wording, I need to say a module implementation unit which is a partition. It is long. If possible, I suggest to add the term module implementation partition unit to the spec to make it shorter. CC Jens.

It seems to me that what you want is a module implementation unit that doesn't import the primary module interface unit.

This is not inherently a partition; you're just using a partition because that's the only way to avoid importing the PMIU. Giving this TU a throwaway partition name that will never be used elsewhere, that only serves to prevent the implicit import, is the first kludge I was referring to. And then suppressing BMI generation for such a partition is a second kludge piled on the first.

The evolution question is whether we want to add a way to express this use case without the throwaway partition name.

First, the motivation of the post is the first one. We need to be on the same page that the current standard wording doesn’t force all implementation units which is a partition to generate BMIs.

For if the proposed practice is good, I must say it makes no sense to suggest to use module implementation units which is not a partition instead. It will import all interfaces. Any interfaces changes will recompile all of the module implementation units which is not a partition. THIS IS NOT ACCEPTABLE if you really write and maintain native modules code in a large codebase in a product.

For how build system can support it, other build systems can support it naturally. e.g., bazel can support it super easily if the module implementation unit which is a partition is not listed in module interfaces. For CMake, there may be some problems due to MSVC’s extension. But, on the one hand, MSVC’s extension is not standard. I don’t understand why we have to consider that in the STANDARD committee. On the other hand, I am not blaming cmake. I am not a user of cmake. I can understand if cmake didn’t implement the optimization due to various reasons. The point is, we need to admit that is an optimization. We can say, in cmake, the optimization was not implemented due to various reasons. But you can’t say the optimization is not legal due to the standard.

I don't see anyone saying that.

Again, the only motivation of the thread is, I want to be sure that the current standard wording allows the practice.

Thanks,
Chuanqi
------------------------------------------------------------------
From:core <core_at_[hidden]<mailto:core_at_[hidden]pp.org>>
Send Time:Thu, Jan 15, 2026, 09:55
To:Richard Smith<richardsmith_at_[hidden]<mailto:richardsmith_at_[hidden]>>
CC:Ben Boeckel<ben.boeckel_at_[hidden]<mailto:ben.boeckel_at_[hidden]>>; core<core_at_[hidden]<mailto:core_at_[hidden]>>; SG15<sg15_at_[hidden]<mailto:sg15_at_[hidden]>>
Subject:Re: [isocpp-core] [isocpp-sg15] [modules] wordings to allow build system to not always emit BMI for implementation partition units

On Wed, Jan 14, 2026 at 13:38:51 -0800, Richard Smith wrote:
> The only purpose of a partition name is to allow the module unit to be
> imported. Is it really worthwhile for a compiler or a build system to
> expend extra effort to avoid a BMI in the case where the developer asks for
> a module unit to be importable but then doesn't import it? (I think this
> can reasonably happen due to the build configuration affecting which source
> files get built, but that seems like it should be pretty rare.)

Non-importability would require knowledge of all TUs that can "see" the
module in the first place. There's no rule that a module cannot span
libraries (CMake targets), so I don't think this is answerable in
general (the "normal" use case I've seen is for test code to be
"adopted" into the module to access otherwise-inaccessible APIs for
testing purposes). There's no way to do such optimizations in CMake as
scanning and collation is performed on a per-target basis with no
knowledge of consuming targets.

It's a lot of build-system work for minimal user gains IMO. We don't
even have comparisons of module strategies to even know how much perf is
even available to such an optimization, so I'd like to start picking up
the cash floating around in the air before we look for coins in the
cushions.

> On Wed, 14 Jan 2026 at 11:15, Ben Boeckel via Core <core_at_[hidden]<mailto:core_at_[hidden]>>
> wrote:
> > Can we get an attribute like:
> >
> > module [[never_imported]] mod:part;
> >
> > to indicate this situation? If the scanner says no BMI will be
> > generated, the CMake (as it currently exists) has no qualms about such a
> > TU being in a non-`CXX_MODULES` file set.
> >
>
> We already have a (shorter) way of expressing that:
>
> module mod;
>
> What value would we get by adding another way to express the same thing?

That's basically my throughts prior to this thread. The one benefit that
has been expressed is that this adds a dependency on the module as a
whole. Other than that, yeah…not seeing much benefit. Certainly not
enough to not have the scanner also understand what is going on in the
first place. If the scanner reports "no BMI" (as the MSVC extension
does), then CMake as it exists today will have no qualms about the file
not being in a CXX_MODULES file set.

Thanks,

--Ben
_______________________________________________
Core mailing list
Core_at_lists.isocpp.org<mailto:Core_at_[hidden]>
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/core
Link to this post: http://lists.isocpp.org/core/2026/01/19221.php
_______________________________________________
SG15 mailing list
SG15_at_[hidden]<mailto:SG15_at_lists.isocpp.org>
https://lists.isocpp.org/mailman/listinfo.cgi/sg15