[Richard]

  * 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?

*If* the programmer asks for that entire translation unit to be importable, then it is reasonable to expect them to pay for what they use. The problem is that we don’t offer a good mechanism to say “here is an implementation for that particular partition of this module, and no, I don’t want to take an interface dependency on the entire module for this particular partition”.


  * 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 existence proof is not always practical or desirable as it implies an interface dependency on the primary module interface unit. Also, in the face of strong ownership, that “mod” can’t be an intermediary/helper unit.

-- Gaby

From: Core <core-bounces_at_lists.isocpp.org> On Behalf Of Richard Smith via Core
Sent: Wednesday, January 14, 2026 1:39 PM
To: core_at_[hidden]
Cc: Richard Smith <richardsmith_at_[hidden]>; Jason Merrill via SG15 <sg15_at_[hidden]>; Ben Boeckel <ben.boeckel_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, 14 Jan 2026 at 11:15, Ben Boeckel via Core <core_at_[hidden]<mailto: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]<mailto: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]<mailto:Core_at_lists.isocpp.org>
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/core
Link to this post: http://lists.isocpp.org/core/2026/01/19219.php