On Sun, 26 Oct 2025, 15:05 organicoman via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

>
>
>
> 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?
>
> Yes Jason, if for example the growth factor of the implementation is
> different, the side effects will be different.
>
> >What implementation details does code
> *need to know* about this?
>
> Some examples would be, growth factor, ×2? ×1.5?....what optimization used
> for trivially copyable value_type... 'noexcept' aware code...etc
>
> >When would it actually *matter* to the
> user, and why?
>
> Local reasoning...
> - I expect copy assignment, then i see mixture of copy
> assignment/construction...why?
> - Test case implementation. If your only way is to test against a text
> string.
> And other reasons not on top of my head right now.
>
> In my little research I'm doing right now, I found that move operations
> are missing something
>
> A move operation should allow to be tested against....
>
> vec.is_moved_from();
>
> Should yield 'true' or 'false'.
>

Why?

What possible difference would that make to any sensible code, and how
would "moved from" be different from any other value state of a std::vector?

Either it's empty, or it's not. But either way, it has a particular state,
why would it matter whether it got there by being moved from, or a call to
clear(), or having an empty vector assigned to it?



Which is not the case in the current state of the language.
>
> >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.
>
> Where am I going with all this?
> The overall idea is to keep a consistent behavior for what a container
> should do, let say, in the Algebraic sense i.e
> One action on the container means the same action on all of its elements.
> And if we need to rename well established things then let that be.
>
> For example, if you analyze what the literature conveys about what a
> moved-from object means, you will find something similar to the following:
> "A moved from abject is in undefined but
>

I think you mean unspecified.

valid state, and the only operations allowed are assignment or destruction"
>

Wrong.


Given the above... then i can assume that :
>
> vec[idx] = val ; // where vec is a moved-from vector, and idx < vec.size()
> before move ops.
>
> Is a well defined operation...since i just assigned a value to a
> moved-from element of a moved-from container, as per the definition above.
>

Nonsense. That doesn't follow from anything above.

You apparently still don't understand what moving a container does. No
elements are moved in most cases, because the storage is moved so there are
no moved-from elements. Or if the container doesn't move the storage and
moves each element, then the code above is ok.


But in reality, that's an undefined behaviour.
>

It depends.


> So what the literature describes as 'undefined but valid stat', is in
> itself unclear and bears many meanings.
>

The literature never uses that phrase.


Which adds to burden of the C++ language, which is already full of those
> fuzzy constructs.
>
> > 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.
>
> Yes i know Jason.
> This question was meant to trigger some brainstorming
> debate...unfortunately other people responding to this thread, give the
> sentiment that they are happy with the current state of the language, and
> any question that would trigger innovation is silly....that's Ok for me no
> problem at all.
>

I'm fine with improving the language. This suggestion doesn't do that, at
all.



>
>
>