Having read through the message, I think there is a misunderstanding I
should clear up first, and that's that a class in std::stable is not an
alias, or copy, or renaming of its std counterpart. std::string is not
the same class as std::stable::string; they are distinct types, with
std::stable::string ONLY acting as an intermediary that facilitates
transport through public interfaces. Unlike std::string,
std::stable::string has a fixed ABI, and because of that, it can talk to
distinct implementations of std::string.

Also, classes don't start out as unstable and then become stable at some
point. A stable class is intended for interoperability, and that
requires that its ABI is known in advance, and identical for all
implementations.

On 11/07/2024 15:49, Thiago Macieira via Std-Proposals wrote:
>>> Can you give examples of Standard Library classes that would be
>>> permanently or long-term marked as unstable?
>>
>> That's a policy decision that goes a step beyond just having a mechanism
>> in the first place, but I would say a class should be unstable if:
>
> I am asking for your opinion which ones those would be. Your paper must give
> some guidance on where you expect this to be used.

Ok, let's take this from the beginning. The current state of affairs is
that all existing classes are unstable. They must be, because they have
no pre-defined ABI, and that's a condition for being stable. Thus, none
of the existing std:: classes (or indeed, _any_ classes) can be passed
through a standard public interface as described in the paper.

What I expect is that this state of affairs persists indefinitely, with
only a small number of new explicitly-stable classes to be added in a
special namespace, provisionally named std::stable. These new classes
have a pre-defined ABI that all implementations must use. And as stated
above, they are not copies of existing classes, but new classes that
only serve to facilitate transport of data through a new-style public
interface.

>> - The class represents a subject that is the focus of active research
>> (e.g. std::regex).
>
> Those aren't standardised yet.

I meant active research in the sense that people are still spending time
figuring out how to do it better, rather than in the context of
standardisation.

>> - The class is sufficiently complex that a period of refinement would be
>> reasonable after the initial implementation. This does not imply that
>> such a class can be made stable later: a stable class needs to have its
>> ABI set in stone from the beginning, to allow interoperability with
>> other implementations and other languages (e.g. std::unordered_map).
>
> For implementations working on implementing a new class, they sometimes have
> experimental markers (std::filesystem comes to mind). They haven't needed the
> standard to tell them how to manage them, so why should they need that now?

Maybe I'm misunderstanding the nature of std::experimental, but I've
always believed that this represents classes that are proposed, but not
yet finalized for standardisation.

My concern is with classes that have been standardized, but cannot be
improved further (in terms of features and performance) because the
class ABI is perceived as being set in stone.

> Mind you, I think it would be a good idea to have a common way of knowing
> which classes implementors think are stable and which ones are still subject
> to change. Your paper should explain that.

Do you think the summary should be more explicit about communicating
class stability? I.e. something like "This document describes a set of
source-level tools to communicate class ABI stability, and therefore the
risk of potential future ABI breakage from any library (not just the
standard library) to its users."

I don't want it to be too wordy but if you think it is unclear I can
change it.

I suspect some of the rest of your comments were predicated on the idea
that classes can 'migrate' from unstable to stable, which was really not
the intention. If you think they are still relevant, let me know and
I'll try to answer them as best as I can.


Hans Guijt