On Saturday 13 July 2024 03:57:23 GMT-7 Hans via Std-Proposals wrote:
> This is why I added the concept of public interfaces. They make it easy
> to do the right thing (and come with alluring bonus of possibly better
> performance), and they won't allow instable types for their parameters.
>
> The current situation is that the Standard never said that classes would
> be stable, but it also never said that classes would not be stable, so
> people have an excuse for using them in public interfaces. With a formal
> definition, there is no more excuse: if you use an unstable class in a
> public interface, that's UB, and the consequences are on you. Neither
> the Standard, nor the compiler implementers, will bend over backwards to
> accomodate you.

While the Standard has not said that de jure, we have a de facto permanence.
Every person working in improving C++ knows the value of permanence, even if
they disagree on how deep it should go. No one is suggesting changing the API
completely and change behaviours. That's the reason why std::regex is still
there and left untouched: it's behaviour and expectation thereof, not ABI.

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?

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel DCAI Platform & System Engineering