When considering how to represent C++, please note some previous work:
Gabriel Dos Reis and Bjarne Stroustrup:
A
Principled, Complete, and Efficient Representation of C++.
Journal of Mathematics in Computer Science Volume 5, Issue 3
(2011), Page 335-356
doi:10.1007/s11786-011-0094-1.
Special issue on Polynomial System Solving, System and Control,
and Software Science.
https://github.com/GabrielDosReis/ipr
Something very similar to that is the representation of modules
in the Microsoft implementation.
Corentin <corentin.jabot@gmail.com> writes: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.Another alternative would be to define an API (naturally in C++ -- it's about time we stopped using other languages for implementing our tools) that can be used to query the compiler-specific binary module interface (BMI) files. Each compiler vendor will then provide an implementation of this API for their format.Libraries could then be distributed with those modules representations [...]Distributing anything generated opens a can of worms. For example, does it mean we check-in these representations into VCS since these days this is the way things are often "distributed"?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).Yes, having a formal API compatibility verification would be very nice indeed. Boris _______________________________________________ Tooling mailing list Tooling@isocpp.open-std.org http://www.open-std.org/mailman/listinfo/tooling