On Friday 12 July 2024 03:35:20 GMT-7 Hans via Std-Proposals wrote:
> > Second, why isn't the current status quo sufficient? The libstdc++ ABI has
> > been kept stable for 20 years now. By that I mean it was intended to be
> > kept stable: all breakages that have happened (and they have) were
> > unintentional, including that of std::__cxx11::basic_string. If they were
> > the result of mistakes, there's nothing preventing mistakes from
> > happening using the newly- marked classes too, so why would your proposal
> > make a more stable ABI than what libstdc++ has delivered for two decades?
>
> The current status quo is not sufficient because it fossilizes every
> class, the moment it is first released. Look at the woes Linux went
> through when the standard mandated SSO over CoW in std::string! Look at
> the performance complaints related to std::regex, std::deque,
> std::unordered_map, etc.! These things happen because of the current
> status quo.

I am looking at that and I addressed in my paragraph: the design was that
libstdc++ would keep ABI and strictly speaking, it did. The issue was
downstream of that library, because it was poorly explained to library
developers. That was a mistake.

So I repeat my question: knowing that there will be mistakes, why is your
proposal *more* stable than the current state of affairs?

> Performance: any transfer through an std::stable class does incur a
> cost, but if carefully designed, that cost should not be more than that
> of an std::move. That is, std::stable::string, if it has a large enough
> SSO buffer, can handle a move from std::string either by copying the SSO
> buffer, or by just moving the pointer. This still implies two moves take
> place (into, and out of std::stable::string), potentially copying as
> much as 64 bytes.

I think you need to put your ideas to the test. Please write a prototype
standard library that shows how this would work, so my questions on cost can
be assessed.

> Porting: this requires adding markup to functions in the public API,
> ensuring that all parameters involved are stable (the compiler will not
> allow unstable parameters), and likely a change to the build script
> since the toolset has to be told it is creating a static or dynamic
> library (this can potentially affect code generation: any function that
> is not part of the public API can be more aggressively optimized. See
> section "new optimisation opportunities" in the paper).

You can start with -nostdlib++ with GCC and Clang for your library.

> While designing a
> stable class requires careful consideration, I would argue that this was
> always the case, even without formalizing the concept of stability in
> the standard.

I agree: they've always been designed with stability in mind. But I came up
with a very different conclusion from this.

> - It doesn't solve the problem, it just moves it to a different spot.
> Different implementations of unstable classes would still serialize
> differently from each other, unless you specify their ABI. This can be
> done much more cheaply using the method I proposed.
>
> - It also still doesn't solve the problem that people would still use
> unstable classes in public interfaces, unless you plan to specify the
> serialisation ABI for every class in the known universe. My solution
> calls for a handful of stable classes, not millions, and as such seems
> more practical.

I thought those two are exactly what you're trying to specify, when you talked
about syscall-like ABIs. From this current reply, it sounds you want something
more like Qt-style ABI which makes each class is just one pointer to the
private implementation and most functions are out-of-line.

Anyway, your proposal will not gain traction without a prototype.

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