On Mon, May 2, 2022 at 2:10 PM Thiago Macieira via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Monday, 2 May 2022 06:23:38 PDT Sébastien Bini via Std-Proposals wrote:
> > However, as others have pointed it out, this leads to an ABI break.
> > Consider:
> >
> > void sink(T z);
> >
> > void fwd_to_sink(T y)
> > {
> > sink(reloc y); // oops
> > }
> >
> > void foo()
> > {
> > T x;
> > fwd_to_sink(reloc x);
> > }
> >
> > In fwd_to_sink, reloc cannot omit the call to the destructor of 'y', as it
> > is called by 'foo'.
>
> Then don't allow relocating a function parameter.
>
> Parameters are always destroyed by the caller and this is required by the
> standard, not the ABI. Therefore, regular parameters shouldn't be relocatable.
>
> Unless you add a new type of reference, which we don't want.
>
> I'm very skeptical about relocating static or automatic lifetime variables.

To me, the entire point of putting "relocation" into the language at
all is to remove destructor calls for things that we can't remove
destructor calls for in any other way. If "relocation" only applies to
dynamic lifetime objects, then "relocation" is a matter of convention,
not of the language. That is, you just don't call the destructor for
it if you relocated it; [basic.life]/5 already effectively declares
that this is fine so long as your program doesn't rely on any
side-effects from the destructor being called.

Any proposal for putting relocation in the language needs to deal with
such variables or else it's not pulling its weight.