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@lists.isocpp.org>

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).