On 22/07/2024 17:39, Thiago Macieira via Std-Proposals wrote:
> On Sunday 21 July 2024 08:51:22 GMT-7 Hans via Std-Proposals wrote:
>> I want to be able to mark some datastructures as guaranteed-stable, and
>> for the rest of the datastructures to have no stability guarantee.
>
> Good. Please explain why this needs to be anything beyond documentation in
> your library.

That's in the paper. The paper presents the problem with the reasons for
solving it this way.

>> 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.
>
> Please explain how that will improve the interface design in C++ in general
> above and beyond what we already have. There must be a problem that prevents
> its current design that makes interfaces currently designed sub-optimal and
> your proposal thus makes easier to achieve and/or maintain.

It will stop people from using unstable classes in their public
interfaces. It will allow you to safely transport strings and vectors
through public interfaces without dealing with manual memory management,
or zero-terminated strings, or _hopefully_ long enough buffers. It will
improve safety, and it will avoid locking every single C++ class into
de-facto stability the moment it is released.

> As for freeing the Standard Library from its current ABI restrictions, have
> you asked the vendors if they want this? There are only three major

No. The process for the ISO standard is laid out on
https://isocpp.org/std/submit-a-proposal. It does not involve "ask
vendors if they want this".

>> And for good measure: I do not want to break the ABI of existing
>> standard library classes either.
>
> Good.
>
> But why is then your goal to allow the implementations to do that?

I have explained this. We currently have de-facto stability, but relying
on that stability is UB because class ABI _can_ change at any moment.

Once stability marking becomes a reality, the standard will formally
describe the consequences of relying on unstable classes in public
interfaces. It will also specify which classes are ABI stable.

That means that classes that are added AFTER stability marking becomes a
reality, CAN and SHOULD BE EXPECTED TO be changed over time. That is,
FUTURE ADDITIONS to the standard library can be expected to be unstable,
and any use of such classes in a public interface is EXPLICITLY UB.

However, since this is a new rule, and since EXISTING standard library
classes are ALREADY used in public interfaces, EXISTING classes,
although FORMALLY unstable, retain their current status as de-facto
stable, in order not to break compatibility of existing software.

So the standard library will be free to evolve NEW CLASSES, but will, by
gentlemen's agreement, refrain from evolving EXISTING CLASSES.

If existing classes are in need of optimisation, vendors are free to
propose adding an unstable class2 version to the standard library. Since
that would count as a new addition, it will default to being unstable,
and therefore open to evolution. This allows targeted improvement of the
worst problems in the standard library.


Hans Guijt