On Wed, Jul 2, 2025 at 7:35 PM Giuseppe D'Angelo via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
On 02/07/2025 19:51, Jan Schultke via Std-Proposals wrote:
> Hi,
>
> I think this paper has excellent motivation and explains the problem
> really well, with plenty of good motivating examples.
>
> Perhaps it would benefit from including a summary of recent discussion
> and polls that took place at Sofia. After all, it was suggested in
> LEWG that a separate trait for bitwise trivial relocation could be
> created.

Very good point, will add some references.

> The wording could be improved a bit.
>
>> and trivially relocating objects of type T by means of calling trivially_relocate
>> does not change the object representation of the objects being relocated.
>
> This does not make too much sense; the original object is killed, so
> in that way, its object representation does change. Also, the original
> object representation doesn't really have to be modified anyway, if I
> understand it correctly. Maybe something like
>
>> and trivially relocating objects of type T by means of calling trivially_relocate
>> is performed exclusively by copying the bytes of the object representation
>> of the relocated object.
>

I fear that "exclusively" here is too strong. I don't want to imply that
a byte copy is sufficient; trivially_relocate doesn't just copy bytes,
it also does lifetime management, which is a necessity for TR-non-TC types.


My intention with the wording was to build on top of this sentence:

https://eel.is/c++draft/obj.lifetime#11.sentence-2

> Otherwise, the range denoted by [result, result + (last - first)) contains objects (including subobjects) whose lifetime has begun and whose object representations are the original object representations of the corresponding objects in the source range [first, last) except for any parts of the object representations used by the implementation to represent type information ([intro.object]).

This is already using a form of equivalence between object
representations ("whose object representations **are** the original
object representations"). What I want to somehow drop is the "except"
part: for a bitwise trivially relocatable type T, there's no "except",
the object representation of the new object is identical (in the
ranges::equal sense) to the object representation of the original object.


> On another note, did you get in touch with the other authors of P1144?
> It's a bit odd to see only one name on this paper.

No, I didn't. I really wanted to have this paper in the next mailing so
this is really the first public draft. Any contributions are welcome.

FWIW, I support this paper of Giuseppe's. However, I get the impression that his strategy — empirically, a very good strategy! — is to make sure his name never appears next to mine in this area.
- P1144 "std::trivially_relocatable" (O'Dwyer) up to R12 was not seen by EWG.
- P3233 "Issues with P2786" (D'Angelo) was seen by EWG at the first possible opportunity, as was P3236 "Please reject P2786 and adopt P1144" (De Freitas, Anderson, D'Angelo, Goudey, Lucke, Stasiowski, Janel, Maciera). At the meeting where P3233 and P3236 were seen, P2786 was recalled from CWG for further discussion by EWG (although P1144 was not advanced to EWG).
- P3516 "Uninitialized algorithms for relocation" (Dionne, D'Angelo) was seen by LEWG at the first possible opportunity, and approved for C++26. Notably, P3516 beat out Bloomberg's P2967 "Relocation has a library interface", which proposed a worse version of the same thing. Notably, P3516 was created by taking strictly the library clauses of P1144.
- P3559 "is_trivially_relocatable: One trait or two?" (O'Dwyer) was seen by LEWG at the first possible opportunity and rejected.
- P1144 "std::trivially_relocatable" R13 (O'Dwyer, Bać, Anderson, Mauro, Hagins, Steffens, Janel, Falco, Brown, Wray) was seen by EWG precisely as soon as procedure ensured that design changes to C++26 were no longer permitted, and was procedurally rejected at that point.
- To be fair, P3631 "Cleaning up the trivial relocation APIs in C++26" (Dionne, D'Angelo) was seen by LEWG at the first opportunity but rejected. (This would have completed the removal of P2786's original API from the library clauses, leaving only the P1144 API. Bloomberg strongly opposed P3631.)

The pattern here is that papers with "O'Dwyer" in the authorship line do poorly; papers with "D'Angelo" do (rightly) get seen and almost always have the desired effect, when the technical content is the same. (And no paper yet has ever had both names together.) So I'm very happy to keep my own name off of Giuseppe's paper. I will try to vote in favor of it at every opportunity, and encourage everyone else to, too.

I'd like to draw attention to Giuseppe's closing line:

In conclusion, adding a type trait that closely models what these libraries have been assuming in the past (20+ years, in the case of Qt) will likely provide a better upgrade path for them.

–Arthur