On Thursday 11 July 2024 04:57:47 GMT-7 Hans via Std-Proposals wrote:
> On 10/07/2024 14:57, Thiago Macieira via Std-Proposals wrote:
> > On Wednesday 10 July 2024 03:01:39 GMT-7 Hans via Std-Proposals wrote:
> >> The focus of the paper is not on how to implement such interfaces,
> >> however, it is on communicating (and enforcing) that library classes are
> >> subject to change in future library revisions, and therefore not safe to
> >> use in public interfaces.
> >
> > 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.

> - Different implementations can deviate considerably from each other in
> terms of ABI (e.g. std::string).

Stop there.

EVERY single implementation will differ in every single class *because* they
are different implementations. Just looking at std::string makes your proposal
a non-starter:

a) std::string MUST be stable for applications to use in an interface

b) std::string already is in the stable category, therefore cannot be moved to
the unstable category, especially with a different mangling name

So let's try again: what *new* classes do you expect this to be used for and
how do you expect those new classes to be managed alongside the old ones?

> - The class represents a subject that is the focus of active research
> (e.g. std::regex).

Those aren't standardised yet.

> - 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?

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.

> - The class can reasonably be expected to be augmented with additional
> features in the future (e.g. std::thread).

Similar to the previous point: implementors already have ways around this. Why
does the standard have to say anything then?

> In my view, the only classes that can immediately be marked as stable
> are those where you can either reasonably expect that multiple
> implementations will inevitably end up with an identical (or nearly
> identical) ABI (e.g. std::chrono::time_point, std::pair), or that are
> designed specifically for the purpose of exchanging data across public
> interfaces.

std::pair is not identical for all implementations for all types.

And moreover, that would be extremely limiting. The ABIs currently don't do
this, so your paper is dead-on-arrival if you suggest that they do something
they don't. You need to explain how it's going to be used *now*, not how it
would have been used if it had been part of the standard draft 30 years ago.

> I would consider this proposal to have failed in its purpose, if it
> meant that every single new class had its ABI specified by the
> committee. Instead I expect classes to be judged on their suitability
> for having a stable implementation, and the vast majority to be
> rejected. The preference should be to give implementers the freedom to
> achieve the best performance possible, and that conflicts with the
> desire for maximum stability.

Then why are you proposing this at all?

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