On Sun, Jul 21, 2024 at 11:51 AM Hans via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> 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_.

But those are not your goals. Those are the means by which you will
*achieve* your goals. Your actual goals being whatever you intend to
do with those "datastructures [marked] as guaranteed-stable". That is,
you want to be able to reliably do something with such data
structures. Those "something"s are your goals. Marking "datastructures
as guaranteed-stable" is the means by which you will achieve them.


> 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).
> >
> >
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals