I think this is the right direction. The mental model for shifting
operations should be relocation, with assignment being an allowed
optimization and not the other way around. The cases where there are
semantic differences (sans exceptions and stuff) are already
conceptually broken, even if they happen to do the "right thing".

Regarding type requirements, AFAICT the only way to populate a vector of
non-move-constructible elements is using the constructor that
default-constructs n elements (deque and inplace_vector have more
options), which means that types that can't be erased via relocation are
even more pathological: they have to practically be both default
constructible and move assignable, but not move constructible (even
though you can "move construct" them using default-construction + move-
assignment).

But the more realistic case is the other way around: types that are move
constructible but not move assignable. They can't be shifted via
assignment, but can be shifted via relocation. I'm pretty sure you're
not proposing that implementations are required to use relocation in
this case (not with this paper, anyway; not necessarily a bad idea in
general), but in several places it says that the requirements of erase()
become "Cpp17MoveAssignable *or* Cpp17MoveInsertable", which suggests
that implementations *are* required to support that.


On Friday, March 20th, 2026 at 2:50 AM, Giuseppe D'Angelo via Std-Proposals <std-proposals_at_[hidden]> wrote:

> Hello,
>
> I've drafted https://isocpp.org/files/papers/D4102R0.html which argues
> that linear containers like `vector` or `deque` (that is, containers
> that shift elements around on insertion and erasure) should be allowed
> to relocate elements, instead of being forced to use assignments, when
> an element is inserted in or erased from the middle.
>
> This was a concern raised by several papers (at least P2959R0, P3278R0,
> P3233R0) during the standardization of trivial relocation in the C++26
> timeframe. This ultimately led to the "replaceable" keyword/trait, which
> was deemed confusing.
>
> In the paper I'm taking a much simpler approach by proposing that
> implementations are free to use either assignments or relocations to
> shift elements around. There's some complications related to exception
> safety but I don't see any particular challenge. (Note that this paper
> doesn't depend on any relocation proposal.)
>
> Thank you for any feedbacks,
> --
> Giuseppe D'Angelo
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>