On Wed, 21 Dec 2022 at 08:29, Ville Voutilainen <ville.voutilainen_at_[hidden]>
wrote:

> On Mon, 19 Dec 2022 at 14:51, Sébastien Bini <sebastien.bini_at_[hidden]>
> wrote:
> >
> > 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.
>
> The problem goes away if the semantics of destructive move are such
> that the destructive-moved-from object is in a state where
> destruction is valid but not necessary.
>

Yes; we don't want that, since then we would be unable to use relocate-only
types such as never-empty types such as not_null<unique_ptr>. For another
example, guard types often need to be relocatable, but move support and an
empty state add considerable complexity, often more than doubling the
amount of code required.