On Wed, Jul 2, 2025 at 7:35 PM Giuseppe D'Angelo via Std-Proposals <
std-proposals_at_[hidden]> 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"
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p1144r11.html> (
*O'Dwyer*) up to R12 was not seen by EWG.
- P3233 "Issues with P2786"
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3233r0.html> (
*D'Angelo*) was seen by EWG at the first possible opportunity, as was P3236
"Please reject P2786 and adopt P1144"
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3236r1.html> (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"
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3516r1.html>
 (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"
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2967r1.pdf>,
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?"
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3559r0.html> (
*O'Dwyer*) was seen by LEWG at the first possible opportunity and rejected.
- P1144 "std::trivially_relocatable" R13
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p1144r13.html> (
*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"
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3631r0.html>
 (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