On Sun, May 22, 2022 at 12:46 PM Edward Catmur via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Fri, 20 May 2022 at 18:52, Thiago Macieira <thiago_at_[hidden]> wrote:
>>
>> I don't think that's sufficient. The change needs to be opt-in, not opt-out.
>> Otherwise, we're going to have silent breakages because of some libraries
>> recompiled and others not.
>
>
> Uh, if a library is not recompiled, then it uses the old ABI, and if it is recompiled then either it's compiled against old source code, so uses the old ABI, or is compiled against new source code with relocation operator defined but also with the opt-out in place, so it uses the old ABI.

I think his point was that you're confusing the terms "opt-in" and "opt-out".

For a feature to be "opt-in", it must be unavailable *unless* you do a
thing that specifically makes it available to you. "Opt-out" is the
*opposite*; you have the feature *unless* you do a thing to turn it
off.

The deletion behavior of defaulted move constructors in the presence
of user-provided copy constructors is an example of "opt-in". If your
type has a user-provided copy constructor, but you don't declare a
move constructor (maybe because you wrote it in C++98/03 where those
didn't exist), then your type's move constructor will be deleted. It
cannot participate in moves. Your type doesn't have a move operation
unless you explicitly ask for one.

That seems to be what you're arguing for here, just with the wrong
terminology. You are describing "opt-in" functionality, but you *call*
it "opt-out".