On Wed, 21 Dec 2022 at 10:31, Edward Catmur <ecatmur_at_[hidden]> wrote:

>> So, rather than have a destructive move where such a semantic
>> restriction would be in place, do you prefer not having destructive
>> move at all?
>
>
> That seems to me a false dichotomy; there is no reason whatsoever why we couldn't have both. As noted elsewhere, the only types for which callee-destroy is an absolute necessity are those which are relocate-only, which currently cannot be passed by value at all, so if implementations choose they can retain ABI compatibility for all class types which can currently be passed by value, even when adding a relocating constructor, trivial or otherwise.

I don't know whether it's a dichotomy, I'm merely trying to figure out
which pieces of this cake are up for bargaining.
I grok the practical need to relocate a container just fine, it's far
less clear to me why I need
to relocate a reloc-only type, or even introduce the concept of a
reloc-only type. What happens if I reloc-move an object and
then try to access it? Is that yet another source of UB? I spy with my
little eye that if the semantic restriction I ruminate on there
is present, that source of UB isn't necessarily introduced.