On Thu, Jan 15, 2026 at 10:36 AM Chuanqi Xu via SG15 <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]>
> Send Time:Thu, Jan 15, 2026, 09:55
> To:Richard Smith<richardsmith_at_[hidden]>
> CC:Ben Boeckel<ben.boeckel_at_[hidden]>; core<core_at_[hidden]>;
> SG15<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]>
> > 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_[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]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>