On Mon, Dec 19, 2022 at 1:11 PM Ville Voutilainen <
ville.voutilainen_at_[hidden]> wrote:

> I don't get it. If we have a new kind of constructor, there is no ABI
> _break_, since it's just a new constructor. So why aren't you adding
> such
> a new constructor for pair?
>
> Since this is a semantic facility with semantic guarantees, using
> attributes here seems like the wrong thing to do.
>

I get your confusion. Let me explain in more detail. Let's say you want to
call this relocation constructor with a function parameter as source
object. This function parameter was passed by value to the function:

void bar(T);
void foo(T val)
{ bar(reloc val); }

To simplify, the reloc call here will call the relocation constructor for
us. When an object is passed to the relocation constructor, its destructor
must not be called. So in the example, foo must not call the destructor of
val. However, if foo's ABI is caller-destroy, then foo doesn't have the
means of doing that, as it is not in charge of calling the destructor of
val in the first place.

FYI if reloc is used on a function parameter and the ABI is caller-destroy,
then the proposal states that reloc falls back to the move constructor
instead of the relocation constructor.

The idea is then to guarantee that we have the callee-destroy ABI for the
purposes of relocation. We don't want to impact all functions, and we want
the library vendors to have full control over which functions will keep
their former ABI/call convention, as ABI stability is important for some.
This is what motivated the following rule: if a function takes a value
parameter whose type declares a relocation constructor (understand, the
class designer allowed relocation) then the function is forced to have the
callee-destroy ABI. Exceptions to this rule are for trivial types (their
destructor is a no-op so we don't care how many times it's called), or for
types defined with the opt-out class attribute.

And the reason for my email is that I'm worried that this simple class
attribute may not be enough, as for instance it is terrible for
composability.