On Sat, 25 Oct 2025, 03:54 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.
>

No, you keep claiming this, but it's not true for moves.


> If the value_type of the container has some side effects for its move/copy
> assignment operators (like a log msg),
>

Logging in constructors of value types is silly, nobody does that except
when learning or debugging.

If the identity of objects matters, you allocate them on the heap and store
smart pointers in the container instead.


that will be very confusing,
>

Only if you're confused already.


and imposes on the user to get in the implementations details of the
> container.
>

All you need to know is that the container is doing the most efficient set
of operations to get the expected result. How it gets there shouldn't be
important.

If your value types care whether they were copy constructed or assigned to,
you're doing something wrong.




> However, if the container keeps a consistent action distribution over the
> elements, and avoid mixing two actions (construction and assignment,
> above), then local reasoning will be sufficient for testing and debugging.
>


Nonsense. Adding yet another form of initialization will not make it easier
to reason about anything. This is a terrible idea, even by the standards of
this mailing list.



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


You can't. This needs something like a borrow checker, which is not
possible in C++ with today's compilers or today's language.


  and the one not yet initialized. Like in this example
> ///
> T t1, t2;
> T* p;
> T* q = &t1;
> *p = t2; // must pick construct by copy assign
> *q = t2; // must pick regular copy assign
> ///
>
>
>
> Sent from my Galaxy
>
>
> -------- Original message --------
> From: Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]>
> Date: 10/25/25 3:23 AM (GMT+01:00)
> To: std-proposals_at_[hidden]
> Cc: Thiago Macieira <thiago_at_[hidden]>
> Subject: Re: [std-proposals] Consistent behavior on Container actions
>
> On Friday, 24 October 2025 17:01:46 Pacific Daylight Time Jonathan Wakely
> via
> Std-Proposals wrote:
> > Why?
> >
> > Your mental model is not how it works, why would we complicate things to
> > support an incorrect model?
>
> Agreed, it seems to apply a pedantic purism of what a container should do,
> instead of being practical. The example of moving is telling: technically,
> moving one container to another could just move all elements - it is what
> a
> container using Small Container Optimisation (like std::string) does. But
> in
> practice, doing that for arbitrarily-sized containers is just wasteful,
> because the operation can in many cases be achieved in O(1), and in the
> worst
> it's an O(n) destruction of the target container's elements.
>
> Non-move assignment usually does try to assign element by element,
> provided
> the target container has that many elements. The question is what happens
> when
> it has fewer: should the container default-construct elements just so they
> be
> assigned to? That might be correct, but it's wasteful.
>
> And if someone *really* needs that, they can just ensure the target
> container
> has the right size before the assignment. There's no need to change
> anything
> in the library.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Data Center Group
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>