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

>
> -------- Original message --------
> From: Sebastian Wittmeier via Std-Proposals <
> std-proposals_at_[hidden]>
> Date: 10/26/25 4:52 PM (GMT+01:00)
> To: std-proposals_at_[hidden]
> Cc: Sebastian Wittmeier <wittmeier_at_[hidden]>
> Subject: Re: [std-proposals] Consistent behavior on Container actions
>
> >You can create a container, which applies >certain operations (like copy,
> move, >empty) on all of its contained objects.
>
> It would be more intuitive to have this as the default.
>
> ///
>
> vec(const vec&) ;// copy each elem
>
> vec(vec&&);// move each elem
>
> vec& operator =(const vec&);//assignment by copy construction or copy
> assign each elem
>
> vec& operator =(vec&&);// assignment by move construction or move assign
> each elem
>

For a container of 1000 elements this would be 1000 times slower than how
it actually works today.

This is still a terrible idea.

void clear();//destroy each elem
>
> ///
>
> The common behavior is that after each operation the source container,
> still have the same capacity and size, and the internal pointer to the heap
> is still valid (!= nullptr). Except for clear() where size =0;
>
> In this scenario, the moved-from state of the container could be
> delegated to its elements, given a conventional protocol...for expl, if we
> agree that we never move individually any element , then it is safe to
> test if the container is moved-from by delegating to one of its element i.e
>
> vec.is_moved_from() <=> vec[idx].is_moved_from();//idx < vec.size()
>

This has no practical benefit, ever.



> >You can create a container, which allows >all or more operations
> (including >is_moved_from()) in its moved from state.
>
>
>
> >What the standard specifies, is a minimum for the classes to follow. Even
> the >standard library containers are allowed >to do more than the minimum
> for a >specific implementation.
>
> The minimum should be the default and the correct behavior,.
>
> Specializing the behavior must be for real special cases.
>
> >A more 'extreme' variant of movement is >relocation.
>
> >Perhaps in all or at least most cases, >the program could (in theory in
> the >future) statically at compile-time test, >whether a variable was
> relocated. Or >alternatively it is possible to reuse the >name after
> relocation.
>
> >A relocated object has no moved from >state, but cannot be accessed at
> all.
>
> In my little side research, i found that the concept of 'borrow checker'
> and 'pointer provenance' combined must be a compiler only concept i.e as a
> user you cannot introduce them into your code, but the compiler use them to
> check for correctness, static analysis and function overload.
>
> Right now, i don't have a full view of how this should be done, but i
> started this thread from the same start point which lead me to the above
> observation.
>
> I assumed it will lead everyone here to the same result, and i was
> interested to see how everyone will tackle it.....
>
> well not everything we assume will happen :|
>
> Anyway...Thanks all for your feedback.
>
> End of thread.
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* organicoman via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* So 26.10.2025 16:05
> *Betreff:* Re: [std-proposals] Consistent behavior on Container actions
> *An:* Jason McKesson via Std-Proposals <std-proposals_at_[hidden]>;
> *CC:* organicoman <organicoman_at_[hidden]>;
>
>
>
>
>
> 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'.
> 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 valid state, and the only
> operations allowed are assignment or destruction"
> 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.
> But in reality, that's an undefined behaviour.
>
> So what the literature describes as 'undefined but valid stat', is in
> itself unclear and bears many meanings.
> 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.
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>