On Tue, 20 Dec 2022 at 19:33, Giuseppe D'Angelo <giuseppe.dangelo_at_[hidden]>
wrote:

> Il 20/12/22 18:51, Edward Catmur ha scritto:
> > There are a few problems with [[trivial_abi]]:
> >
> > * ABI break when you add it to existing classes
> > * breaking compatibility if you use an old compiler or a compiler that
> > doesn't support it
> >
> > Between these I think it would be unlikely that libstdc++ would adopt
> > it, and that means that g++ is likewise unlikely to implement it. I
> > could be wrong though.
>
> Sure -- but I was not advocating specifically for [[trivial_abi]]; I was
> using it as an example of a _proven_ performance improvement that a
> different ABI can bring, and yet, it's behind an opt-in (rather than
> just going ahead and breaking ABI).
>

This proposal would not be an automatic ABI break; it would always at
minimum require some action on the part of the user to change ABI for
existing types, if there were to be an ABI break at all.

Some libraries enable [[trivial_abi]] automatically unless opted out; for
example Niall's Boost.Outcome
https://github.com/boostorg/outcome/blob/2d999f9da660ce27c1e06c2551723ccfc3c8cd95/include/boost/outcome/config.hpp#L201

This was in the context of the fact that adding a relocation constructor
> to something like unique_ptr would instead automatically be ABI breaking
> unless there's an opt-out, and I was wondering if that was a good idea.
>

It would not necessarily be ABI breaking; that would be the choice of the
implementation (or of the ABI working group, in the case of Itanium). For
platforms that are already callee-destroy, adding a nontrivial relocating
constructor would almost certainly not break ABI.

My 2 c,
> --
> Giuseppe D'Angelo
>