On Wed, 14 Jan 2026 at 11:15, Ben Boeckel via Core <core_at_[hidden]>
wrote:

> On Wed, Jan 14, 2026 at 11:28:59 +0800, Jason Merrill via SG15 wrote:
> > On Wed, Jan 14, 2026 at 10:09 AM Chuanqi Xu via SG15 <
> sg15_at_[hidden]>
> > wrote:
> >
> > > > IMO, if you have a non-exported partition that you don't want
> exported,
> > > remove the partition name. It can (must) then be listed outside of a
> > > `CXX_MODULES` file set and won't make a BMI (whatever the costs may
> be).
> > > The standard already has a mechanism to do the "part of a module, but
> > > not making a BMI". Why do we need another subflavor of translation
> unit?
> > >
> >
> > IIUC the issue is that if you have a TU that implements the interface of
> a
> > particular partition, and only needs to import that partition, removing
> the
> > partition name creates an interface dependency on the entire module,
> > resulting in unnecessary rebuilding if a different interface partition
> > changes.
> >
> > Chuanqi proposes to handle this by giving the implementation unit its own
> > dummy partition name, and then wants a way to suppress BMI generation for
> > that dummy partition. But this seems a bit like piling kludge on kludge
> to
> > work around the lack of a way in the standard to specify an
> implementation
> > unit for a specific partition.
>
> Ok, not wanting the dependency on the entire module makes sense to me.
> However, IIUC, this causes confusion on the MSVC side. Right now, a TU
> `module mod:part;` can have two meanings:
>
> - in a `CXX_MODULES` file set -> add `-internalPartition` and get a BMI
> - not in a `CXX_MODULES` file set -> "partition implementation" MSVC
> extension
>
> Adding support for "internal partition that does not make a BMI" to
> Clang and GCC sounds fine, but I'd prefer that the *scanner* report that
> it won't make a BMI (so that the compiler doesn't dump a BMI somewhere
> that CMake isn't tracking; how else will the compiler know this BMI is
> unwanted?).


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.)

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?


> 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/19219.php
>