On Tue, 20 Dec 2022 at 19:33, Giuseppe D'Angelo <giuseppe.dangelo@kdab.com> 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