Let's get back for a moment to my goals, because we are drifting away
from them. Here goes:


***************

I want to be able to mark some datastructures as guaranteed-stable, and
for the rest of the datastructures to have no stability guarantee.

I hope that this will improve interface design in C++ in general (for
all libraries), and over time also free the standard library from its
current ABI concerns.

***************


That's it. That's _all_. Everything else I wrote is a means towards
achieving this. 'Public interfaces' is only a carrot to make programmers
more likely to use this. std::stable::string is only there because
exchanging text is such a common thing, it would be mad not to support it.

I don't want to "just add a new string class". The string class was only
ever an example of something that would be incredibly useful to have,
because text is such a common thing to exchange. And creating such a
class outside the standard - honestly, what good would one more
non-standard string class do? It's ONLY power comes from it being
blessed by the standard as _the_ class to use for exchanging text on
public interfaces. Not having such a fundamental vocabulary type in the
standard just makes a mockery of the whole idea.

I also don't want to change the platform ABI or provide a solution for
combining multiple different platform ABIs. I was very careful in
specifying that I considered that to be out of scope.

And for good measure: I do not want to break the ABI of existing
standard library classes either.

Coming back to your questions: std::string_view is great for passing
text into a function, but it's not so ideal for passing text out of a
function.


Hans Guijt



On 18/07/2024 18:09, Sebastian Wittmeier via Std-Proposals wrote:
> 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).
>
>