On Thu, May 23, 2024 at 14:34:44 -0700, Michael Spencer via SG15 wrote:
> Yes, to support "interface only" modules we need some syntax attached to
> the module declaration. The next question is does that mean that only the
> compiler generated symbols are weak? Or that even strong definitions
> belonging to the module are made weak?

My gut says that everything in the object needs to be weak because we're
going to be making such objects at multiple points in the
(package-level) build graph and they'll meet at link time. There's no
way to guarantee uniqueness of objects with a given set of symbols with
this kind of mechanism.

> There's also two different ways to handle this. One is that you can have
> multiple object files for an interface unit in a single program, but you
> only need one per build environment. The second is that every TU that
> imports (transitively) that interface unit needs to emit all used symbols
> into its object file. The second is terrible and brings us back to headers
> in terms of codegen cost. I'm not sure if CMake can do the first option
> though. It would be very nice to not support the second option.

CMake can do the first option if dependency scanning says "consumers
need to make their own object files for this module". This would need
in-code annotations on every module, partition, etc. Basically, we need
a P1689 update to add a new `bool` to the `provides` entries.

I really fear the ODR looking over the horizon here, but without
complicated setups actually tripping it with bad consequences…it's hard
to convince.

--Ben