If I recall current understanding correctly, it is believed that libraries
will need to provide supplemental metadata files alongside their headers if
those headers are intended to be consumable as header units. Otherwise,
scanning for header units and constructing build graphs will not be
feasible in general. This means we probably won't be trivially enabling
header units at scale. Not by flipping on some compiler flags anyway. There
will be at least some mild repackaging involved. And it's possible that
that work is a similar amount of effort to providing named modules,
especially if we can develop tools to produce primary module interfaces for
existing C++ libraries.

Importing header units might be cheaper than importing named modules on the
consuming side, but again, maybe it's about as affordable to have tools
that suggest replacing an include with an import?

Either way we haven't seen particular papers about what those metadata
files for header units will look like nor about how they will be discovered.

Most of my personal dissatisfaction with header units boils down to the
relative lack of investment into making them work, at least outside of a
well-governed monorepo. Possibly the existing experience using non-standard
analogs has been mostly confined to those kinds of environments, and
possibly there is little incremental benefit to those stakeholders to
provide the same functionality in a more portable way.

If there was a big mistake in standardizing modules, it was in not getting
experience in the practical matters of adopting modules, including building
and packaging them, before changing the language standard. In the future,
language proposals that have implications for the C++ ecosystem should
include experience reports that demonstrate impact (or lack thereof) on
relevant parts of existing C++ tools like build systems, package managers,
and analyzers. I would put contracts in that category of language proposal,
though I believe its demands on the C++ ecosystem would be less substantial
than what we are seeing with modules.

Bret

On Fri, Nov 17, 2023, 06:09 Daniela Engert via SG15 <sg15_at_[hidden]>
wrote:

> Am 17.11.2023 um 08:39 schrieb Ville Voutilainen via SG15:
> > On Fri, 17 Nov 2023 at 09:16, Boris Kolpackov <boris_at_[hidden]>
> wrote:
> >> Ville Voutilainen via SG15 <sg15_at_[hidden]> writes:
> >>
> >>> I would hesitate to suggest or leave room for the impression that
> >>> modules were standardized without adequate tooling consideration.
> >>> Furthermore, some new language facilities just do have adoption
> >>> challenges, that's sometimes the nature of the beast. The
> >>> tooling-feedback from e.g. build system developers hasn't thus far
> >>> revealed a need to do major design surgery to modules, as far as I
> >>> have understood.
> >> To add to what Ben said, there is a growing sentiment in the community
> >> that header units are basically unimplementable and should just be
> >> dropped.
> > Fascinating. There was a time when they were OMDB-insisted to be a
> > must-have, and
> > were said to be the bee's knees and the only form of modules that can
> > ever work, and
> > named modules were said to be the polar opposite of that and
> > completely pointless,
> > by some parties involved. It's truly fascinating if we then end up in
> > a situation
> > where we have named modules with strong ownership and don't bother
> > with importable
> > headers. I mean, that was a likely outcome anyway, the only unclear
> > thing was what
> > the migration path to that point will be. :P
> Current experience shows that named modules work well and are the way
> forward. Despite premature declarations of the death of header units,
> they *are* implementable (as extensive use shows) and have their uses.
> For (a small and minor) example, my modularized standard libraries for
> e.g. libstdc++ and ms-stl are testiment.
>
> I totally agree with the sentiment that implementing them *correctly* -
> in particular when it comes to tooling. They are the most problematic
> and difficult thing in the whole modules realm. I think, there is an
> impedance mismatch: once touted as "the easy path to modules", it is
> quite the opposite in reality. Agnostic of any experience, people are
> asking me on every occasion how they can use their existing libraries by
> converting their headers into header units. And they are only mildly
> deterred when they learn that they have a longer way to go than they've
> anticipated before. I'm obviously failing in teaching how to properly
> create modules - despite all my efforts in the past years.
>
> Dani
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>