Hi Thiago,   that is perhaps the best precedence for what Hans intends with the paper. Have a list of classes that are and stay compatible across compilers and standard library versions. As libc++ decided for typeinfo and  std::exception   But it also shows, where it is currently done: The standard libraries and their open-source or commercial maintainers decide their amount of compatibility as a goal.     So far Hans suggested in the paper and on the mailing list as candidates:   Trivial lists pair, span, string_view   More complex "lists" string, vector   Units time_point   Error handling runtime_error, logic_error, expected     I do not understand, why to include more complex types like std::string? Why not just string_view instead? Why include vector, if you can include span?   Types like string_view and span are defined simple and clear enough that an explicit paper demanding their extraordinary stability is not necessary. However, a paper recommending to use those existing types for more ABI stability and compatibility is not bad per se.   Best, Sebastian   -----Ursprüngliche Nachricht----- Von:Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> At best that would allow libstdc++ and libc++ to exchange data. But do note this was EXPLICITLY rejected as a design goal for libc++. When it was created, it was created with a specific set of classes that are compatible with libstdc+ + but they do not include std::string (it's just typeinfo and std::exception).