On Mon, 19 Dec 2022 at 21:21, Giuseppe D'Angelo via Std-Proposals <std-proposals@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals