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:

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.