<div dir="ltr">I have been thinking about modules portability / tool-ability a bit.<div><br></div><div>I think it&#39;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.</div><div>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.<br></div><div><br></div><div>I propose that conforming compilers must generate when compiling a module interface both:</div><div> * 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)</div><div> * A defined, non compiler specific &quot;universal&quot; module interface representation.</div><div><br></div><div>That universal representation would be such, that, every conforming compiler must generate an identical  (or directly comparable ) file given the same ( preprocessed) source file.</div><div>That universal representation may not be used for compiling a program that depends on the module it describes ( that&#39;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.</div><div><br></div><div>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&#39; CppCon talk)</div><div><br></div><div><br></div><div>I don&#39;t know what a good format for such &quot;module description file&quot; would be, would human readable text be sufficient ? Can we easily represent concepts definitions, for example ?</div><div>Maybe we could extend that format to contain additional information such as documentation.</div><div><br></div><div>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.</div><div>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&#39;t depend anything else than the formally describe API).</div><div><br></div><div><br></div><div>What do you think ?</div><div> <br></div><div>  </div></div>