On Sunday, 22 May 2022 16:32:30 PDT Edward Catmur via Std-Proposals wrote:
> Next, it opts *out* of the ABI
> change, by annotating the relocation operation with an attribute. This
> opt-out means that the class is passed into functions as if it did not
> declare the relocation operation, so this is compatible with previously
> compiled code and with code compiled to an earlier standard version with
> the relocation operation #if defined out.

I repeat that every function must be annotated for their choice too, not the
type. Types are used in libraries other than that which defined them. And that
should be opt-in.

Which makes this feature extremely onerous.

> Both opt-in and opt-out propagate to derived and composing classes as
> necessary to maintain the Rule of Zero. ABI break (opt-in without opt-out)
> also propagates (a class that breaks ABI for itself is assumed responsible
> for breaking the ABI of derived and composing classes) but can be canceled
> by the derived/composing class itself opting out.

The problem is that we have actually a three-way question here for Rule of
Zero.

You can break the Rule of Zero to add your own (non-trivial) destructor and
then opt-in to relocation.

You can keep the Rule of Zero and if your type is already trivial, it gets
trivial relocation. That requires no ABI break because it doesn't matter how
many times you do no-op, it's still no-op.

The problem is when you keep the Rule of Zero on a type that is not trivial
because one of its bases or member sub-objects isn't trivially destructible.
That means the choice of this other type of adding a relocation operator
affects the current type, as per the discussion on synthesising relocation
operators. Unless I misunderstood it, of course.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering