Hello,

Thank you for the review!

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.


Thank you again,
--
Giuseppe D'Angelo