I've gotten tired of this back and forth. I'm gonna put it like this, think
of ABIs like text.
When the only software it talks to is compiled by the same developer the
dev can use
whatever bloody encoding they like, other software be damned. But as soon
as talking
other software becomes necessary (such as a GUI library) the only real
option is unicode.
If you try any other encoding you'll be lucky if it's understood you
correctly.

Likewise with ABIs. When the only software the ABI talks to is software the
dev compiled
then the dev can use whatever optimisations on that ABI they want. The
moment they
need to talk to other software (say the OS itself) there are no ifs, buts
or whats about it,
they MUST use the ABI the OS has provided. std::stable as I see it just
takes this concept
to communicating between different software in general, not just the OS.

For example libraries currently insist on std::strings internal string
being passed to them
so they can make a copy for themselves. They might have some wrapper
inlines or
something to smoothen the process but that still requires the dev to define
something
like IMPLEMENT_LIB_STATICS to for the linker to have something to link those
inlines to. Implementing std::stable could provide those very libraries a
means to use
the string directly without potentially needing a copy. std::string may
inherit directly from
std::stable::string and just override some methods for optimisation
purposes, or it might
do it's own thing and make a std:stable whenever it's required to do so.

As for avoiding ABI mistakes in std:stable, there's no reason you can't
just make it something
like std::stable::string::ver2024 for instance. Rather you SHOULD put
versions into the names
since that gives the option of changing the ABI at any given moment. You
just then add to
std::string's docs that it could inherit from std::stable::string::x or it
might do it's own thing.
After some years have passed enough developers will have seen those docs
that you can
begin considering if any changes to std:string's ABI need to be made but
not ever consider
changing the ABI of std::stable::string::ver2024, instead opting to make
std::stable::string::ver30XX or whatever for std::string to inherit from
once the ABI for it has
been decided on.

On a different note I'd say std::stable is a bit too verbose, perhaps
shorten it to stdabi? Then
just mandate that stdabi cannot be vendor defined at the ABI level, only at
the implementation
level and even then, only if it does not effect the expected behaviour of
stdabi. I expect over
time stdabi:: would become it's own thing and vendors would still have the
option of std:: for
their own experiments.

On Sat, 13 Jul 2024 at 14:55, Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Saturday 13 July 2024 06:29:03 GMT-7 Thiago Macieira via Std-Proposals
> wrote:
> > The standardisation process is supposed to iron out the behaviours until
> > everyone agrees that they are suitable enough to stay in the Standard
> > Library for two decades or more. No one is asking the volunteers to be
> > clairvoyants, so shifts in knowledge can happen. No one is asking them to
> > be infallible either, so mistakes can happen too. Further, where they
> can't
> > agree on what the behaviour should be but agree we need something, we
> > already have a solution, in the form of Technical Reports and
> implementors
> > have solutions to provide experimental, unstable ABI functionality for
> > testing.
> >
> > So I ask again: what does your proposal provide that we don't already
> have?
>
> How about this: let's rename your namespaces, so instead of marking which
> ones
> are stable, we mark the ones that are not. Let's call the experimental
> API/ABI
> std::ext and the one that is stable std::
>
> How is that different from what we have today?
>
> I'm serious: what does your proposal add to the requirements of
> standardisation and on implementations that would lead to a different
> outcome
> of what we already have today?
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel DCAI Platform & System Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>