[2025-02 CWG Motion 8] P2786R13 Trivial Relocation

[AlisdairM]

Fixes #7658.
Also fixes cplusplus/papers#1463

Added freestanding to the lib feature-test macro, as all new parts are marked as freestanding.

Picked the most appropriate location within the type traits spec for each of the three new traits.

[lorihughes]

The comma after object is causing grammatical issues in this sentence.
Unless specifically stated, it is unspecified whether X is replaceable.
The comma separates X from its verb, "is replaceable."
My suggested correction is
Unless specifically stated, it is unspecified whether any class for which move
assignment is semantically equivalent to destroying the assigned-to object and
then move-constructing from the source object in its place is replaceable.

[jwakely]

"Unless specifically stated" isn't what we'd usually say, is it? Was "unless otherwise specified" avoided so we don't have "specified ... unspecified"?

Even without that comma, we still have "whether any class" very separate from "is replaceable".

How about more like:

Except where explicitly stated, it is unspecified whether any class is replaceable if that class' move assignment is semantically equivalent to destroying the assigned-to object and then move-constructing from the source object in its place.

Are "assigned-to object" and "from the source object" clear enough? It be better to introduce two objects a and b and refer to them by name?

[jwakely]

The previous paragraph has the same structure of course, so should match. I'm not sure my suggestion makes things any better though.

[lorihughes]

Yes, we were trying to avoid being repetitious with the "specified" and "unspecified".

In a perfect world, we would get rid of the "it is" because what is meant by that "it" is "whether any class for which move assignment is semantically equivalent to destroying the assigned-to object and then move-constructing from the source object in its place is replaceable"

Except where explicitly stated, whether any class is replaceable if that class's move assignment is semantically equivalent to destroying the assigned-to object and then move-constructing from the source object in its place is unspecified.

Another idea:
Whether any class is replaceable if that class's move assignment is semantically equivalent to destroying the assigned-to object and then move-constructing from the source object in its place is unspecified except where explicitly stated.

[jensmaurer]

This urgently needs meta-variables. And we need to move "is unspecified" or "is replaceable" earlier.

Suggestion (and, by tradition, we don't start sentences with "Whether")

Unless explicitly stated otherwise, it is unspecified whether a class C is replaceable if assigning an xvalue a of type C to an object b of type C is semantically equivalent to destroying b and then move-constructing from a in b's place.

[lorihughes]

Overall, your suggestion is much better, Jens, and I will accept the pain of "it is"

[jwakely]

I like that, and it also avoids my next question, which was going to be whether "move assigning" means invoking a move assignment operator specifically, or just assigning an xvalue, and whether the distinction even matters here (I don't think it does).

Does it matter whether we say "move-construction from a" or "constructing from `std::move(a) in b's place"?

[jensmaurer]

a is already an xvalue, so we don't need std::move around it. Yes, we can drop the move- from "constructing".

[AlisdairM]

Integrated feedback and added cross-references --- I believe this thread should be addressed now.

[jensmaurer]

We don't say "Unless specifically stated" elsewhere, but we do use "Unless explicitly stated otherwise," a few times. I think I would prefer the latter phrasing, putting more emphasis on deviation ("otherwise").

[lorihughes]

I like "Unless explicitly stated otherwise"

[AlisdairM]

Integrated feedback and added cross-references.