On Fri, Oct 24, 2025 at 10:54 PM organicoman via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Given a container of capacity 8, but has 5 elements.
> Let copy assign to it a container of same capacity and full (8 elements)
> All current containers implementation mixe two operations,
> 5 copy assignment + 3 copy construction.
> The same for move assignment:
> 5 move assignment + 3 move construction.
>
> If the value_type of the container has some side effects for its move/copy assignment operators (like a log msg), that will be very confusing, and imposes on the user to get in the implementations details of the container.

Does it impose anything, though? What implementation details does code
*need to know* about this? When would it actually *matter* to the
user, and why?

Copy assignment and copy construction fundamentally should yield the
same result: two objects with equal values. No code should *care* if
this is accomplished by constructing a new object or assigning into an
existing one; the result ought to be the same. That's what "copy"
means, and if your code cares about the difference, then I would
suggest that its idea of what "copy" means is incorrect.

The same goes for movement, but even moreso (and that's ignoring the
issue everyone else brought up about how moving in containers ought to
work).

Your code can tell the difference. But I submit that if it *cares*
about the difference in some meaningful way, your code is wrong to do
so.

> Apart from this explanation. As a free question, how can we tell the difference between dereferencing a pointer to an object within its lifetime, and the one not yet initialized.

You aren't supposed to be able to tell from within the code; that's on
you to pay attention to. That's why dereferencing a point to an object
past its lifetime is UB instead of ill-formed. You have the
responsibility to know what you're doing if you're playing with raw
pointers.