On Mon, 2025-06-09 at 08:44 -0400, Arthur O'Dwyer wrote:
> On Mon, Jun 9, 2025, 7:12 AM Avi Kivity via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> > On Sun, 2025-06-08 at 21:33 +0100, Jonathan Wakely wrote:
> > >
> > >
> > > On Sun, 8 Jun 2025, 09:46 Avi Kivity, <avi_at_[hidden]> wrote:
> > > > On Sat, 2025-06-07 at 22:25 +0100, Jonathan Wakely wrote:
> > > > >
> > > > >
> > > > > On Sat, 7 Jun 2025, 22:20 Avi Kivity via Std-Proposals,
> > > > > <std-proposals_at_[hidden]> wrote:
> > > > > > On Sat, 2025-06-07 at 21:57 +0300, Ville Voutilainen via
> > > > > > Std-Proposals wrote:
> > > > > > > On Sat, 7 Jun 2025 at 21:44, Robin Savonen Söderholm via
> > > > > > > Std-Proposals
> > > > > > > <std-proposals_at_[hidden]> wrote:
> > > > > > > >
> > > > > > > > You can easily implement your own version of optional
> > > > > > > > that does exactly that (it would even be a simpler
> > > > > > > > class to implement, although not to use). The question
> > > > > > > > then is why? If you somehow think that you would gain
> > > > > > > > performance out of it, then my suggestion is: implement
> > > > > > > > this type of optional and show both a benchmark where
> > > > > > > > it makes a significant difference and tell us the use
> > > > > > > > case where this performance gain can be leveraged.
> > > > > > > >
> > > > > > > > My 2 c.
> > > > > > >
> > > > > > > That's easy. The hard part is figuring out how to deploy
> > > > > > > such a type
> > > > > > > with the same name as its previous version that didn't
> > > > > > > use
> > > > > > > the dummy value protocol. It's a behavioral ABI break
> > > > > > > without any
> > > > > > > layout ABI break.
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > This was solved already when std::string changed its ABI.
> > > > > > The compilers shipped the standard library compiled in both
> > > > > > modes for a while, then dropped the old mode.
> > > > >
> > > > > We didn't drop it, both modes are still supported (by a
> > > > > single binary) and in use today, and it took a year of my
> > > > > life and I don't want to do it again :-)
> > > > >
> > > > > And it still has costs today for every change to std::string
> > > > > (as we have to decide whether to implement the new stuff for
> > > > > the old mode too).
> > > > >
> > > >
> > > >
> > > >
> > > > Do people use the old string ABI?
> > >
> > > Yes, even with the very latest GCC releases, and not just because
> > > they're stuck on an ancient Linux distro.
> > >
> > >
> >
> >
> > Amazing. I guess they're stuck with third-party object files that
> > cannot be updated.
>
> Yep. For example, my employer's codebase incorporates a third-party
> static library for talking to a Vertica database, which library is
> (or, from my non-expert viewpoint, seems to be) available only for
> Linux, only for libstdc++, and only for the old libstdc++ string ABI.
> This means that the program we want to link against it (the program
> that needs to talk to Vertica) must be compiled with a special set of
> flags and can't be compiled except on Linux to begin with. That's
> obviously a terrible position to be in, but empirically somebody
> decided it was better than the alternative of just not being able to
> use this third-party Vertica library at all. (Or possibly, just
> better than figuring out how to update that library!)
>
> I won't defend the absolute rightness of our cost/benefit analysis
> there; but I do offer it as a concrete example of someone in
> production still relying on the old string ABI even in the year 2025
> — an answer to "Do people still use the old string ABI?"

Acknowledged. But today, such users can be moved to containers, and I
don't see that a 10-year-old program needs a 1-day-old compiler. I
think a 10-year deprecation cycle for ABIs is reasonable - an ABI lives
for 20 years, and 10 years into its life we launch the next generation
with accumulated fixes.