On Mon, 19 Dec 2022 at 21:21, Giuseppe D'Angelo via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On 19/12/2022 18:05, Edward Catmur via Std-Proposals wrote:
> > This last point seems very unreasonable to me -- it sounds like the
> tag
> > should be the opt-in to the ABI break (a bit like [[trivial_abi]]
> is),
> > not opt-out.
> >
> >
> > The same goes for adding any of the Rule of Five special member
> > functions. Basically, Don't Do That if you want to preserve ABI.
>
> If I have a type that honors the RO3, and I "optimize" it by adding move
> operations (e.g.: std::vector), that doesn't break ABI.


True, but you may well have ODR violations.

Does such a type
> benefit from a relocation constructor, or would it be pointless to add
> one? Does the eventual benefit outweigh the ABI break that would be
> brought in by the constructor?
>

It may benefit from a relocating constructor. It depends how often you
expect it to be passed by value (or returned in contexts not amenable to
RVO) or otherwise relocated (e.g. during a std::vector reallocation or
shuffle). The weight that you put on ABI break would bear on this; this
differs by context. Some people only ever deploy binaries built at once,
with no shared objects, and so have zero concern over ABI.

It may help that the ABI break could be diagnosable, though implementors
would be under no obligation to do so.

If I have a move-only type (e.g. unique_ptr), would I want to add a
> relocation constructor to it? If yes, would I want the associated ABI
> break, considering we live in a world where people don't want the ABI
> break that would improve its moves and we could obtain _today_?
>

Well, that's why Sébastien is proposing the attribute. You still get some
benefit for relocations occuring other than for argument passing. If you
don't care about ABI you would definitely want the break.

Also, which current potential ABI break are you referring to?

Or is relocation just meant to introduce new *kind* of types --
> relocatable-but-non-movable types, so types that don't exist today, so
> there's actually ... nothing to break?
>

That's one of the principal benefits, but by no means the only one.


> (Again, apologies for the straightforward questions, please just leave
> me a link to a paper and I'll read the fine printing :-)).
>

The original thread does answer many of these questions. It is a long read,
of course. Please be patient!

Thank you,
> --
> Giuseppe D'Angelo
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>