I’m leaning to fallback for generic code purposes.

On Sat, May 23, 2026 at 5:27 AM Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> One question is, for containers where unstable operations have no
> advantage, should there still be a fallback to the usual erase? For generic
> code?
>
> Or should it be reserved for the cases, when there is a performance
> difference?
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* 佟晓晴 via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Sa 23.05.2026 14:15
> *Betreff:* Re: [std-proposals] Proposal draft: unstable erase operations
> for std::vector
> *An:* std-proposals <std-proposals_at_[hidden]>;
> *CC:* 佟晓晴 <bfzgsz_at_[hidden]>;
>
> Hi Jens,
>
> Thank you very much for the feedback.
>
> > Sounds like a useful thing.
>
> That is encouraging to hear.
>
> > Where did P0041 go? It's not in the Working Draft.
>
> Good point. I will look into the history of P0041 more carefully and add a
> short discussion to the next revision of the paper. My current
> understanding is that the functionality did not make it into the Working
> Draft, but I should not treat the earlier paper as sufficient precedent
> without explaining what happened to it.
>
> > I think we want this for all of std::vector, std::inplace_vector, and
> > std::deque.
>
> I agree that `std::inplace_vector` is a natural candidate, since it has
> essentially the same vector-like dense-sequence motivation as `std::vector`.
>
> But for `std::deque`, I agree that the paper should discuss it explicitly.
> However, I need to analyze it more carefully before deciding whether it
> should be part of the initial proposed wording. The original motivation is
> the common vector-like “move from the last element and pop” idiom, where
> the reduction in element movement is very direct. For `std::deque`, the
> benefit and specification details may require separate discussion.
>
> I will revise the scope to discuss these containers explicitly. One
> possible direction is to propose overloads for all of them, or at least to
> explain why any of them should be excluded from the initial wording.
>
> > Also, the narrative could benefit from a comparison against std::hive
> > (an entire container where relative order is not preserved).
>
> Agreed. I will add such a comparison. My intended distinction is that
> `std::hive` is a different container choice for workloads that want
> efficient erasure as part of the container model, with different storage,
> iterator, and locality tradeoffs, while `unstable_erase` is meant for
> existing `vector` / `inplace_vector` use cases where the user still wants
> that container’s storage and access characteristics but does not require
> preservation of element order during erasure.
>
> In other words, I do not see this proposal as competing with `std::hive`,
> but rather as standardizing a small operation that programmers already
> write manually when they deliberately choose a vector-like container.
>
> > Of course, otherwise there is no point in having this special thing.
>
> Agreed. I will make the complexity model central to the proposal. The
> operation should not merely be an order-unstable spelling of `std::erase`;
> it should specify the intended reduced-relocation behavior. I will revise
> the wording and benchmarks accordingly.
>
> > What do you mean? I don't think we want this to do more than
> > basic exception safety. Is there a problem achieving that, even
> > if move assignment throws?
>
> I agree that basic exception safety is the right target. I raised the
> question because the operation may move-assign or otherwise relocate an
> element from the back into an erased position, and I wanted to avoid
> accidentally specifying a stronger guarantee than implementations can
> reasonably provide for all `T`.
>
> I will update the paper to state the intended basic guarantee and analyze
> the case where move assignment throws. I do not intend to require a strong
> guarantee.
>
> Thanks again. I will prepare a revised draft that incorporates these
> points.
>
> Best regards,
> Xiaoqing
>
> --
> 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
>