I have been thinking about modules portability / tool-ability a bit.

I think it's probably unrealistic and undesirable to constrain the format
of modules files as that would probably limit the opportunities for
performance optimization and it is important that modules be as fast as
possible.
However, there is a also a need for modules to be easily tool-able for the
sake of IDE implementors and other tools, including maybe package managers.

I propose that conforming compilers must generate when compiling a module
interface both:
 * A non portable, implementation-defined module interface file that may be
digested by that specific compiler (like it is the case today, as per the
module TS)
 * A defined, non compiler specific "universal" module interface
representation.

That universal representation would be such, that, every conforming
compiler must generate an identical (or directly comparable ) file given
the same ( preprocessed) source file.
That universal representation may not be used for compiling a program that
depends on the module it describes ( that's what the non-portable
representation is for), but it should be sufficient for a tool to reason
about a module. It should therefore contain all the declarations exported
by that module.

Given two universal representations generated from different versions of
the same (preprocessed) sources, once should be able to determine if the
versions are identical, API compatible, or not API compatible - That
implies to formally describe what constitutes an API break in a module
(Assuming consumers follow the rules for API consumption described in
Titus' CppCon talk)


I don't know what a good format for such "module description file" would
be, would human readable text be sufficient ? Can we easily represent
concepts definitions, for example ?
Maybe we could extend that format to contain additional information such as
documentation.

Libraries could then be distributed with those modules representations such
that IDE would be able to parse them without the need for the modules
sources or compiled interfaces to be present, solving a lot of concerns
people have regarding modules.
For package managers, it could provide a mean to enforce semver at the API
level (aka that, the dependent project will still build when the source
dependency is updated, as long as they don't depend anything else than the
formally describe API).


What do you think ?