My question here is,
What concrete problem would this be solving?

Because I don't think it solves the problem you think it solves.

-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> On Behalf Of Hans via Std-Proposals
Sent: Thursday, July 11, 2024 18:08
To: std-proposals_at_[hidden]
Cc: Hans <hguijtra_at_xs4all.nl>
Subject: Re: [std-proposals] ABI

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







--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals