This whole discussion brings a few ideas concerning this problem.

1) The name unstable_erase: I do think that it would be better to have it for all containers. We might rename it to fast_erase to make it clear why we want it in the first place. This name also would make sense for std::list, for example. Erasing with an iterator is always fast on a list. On the other hand, the name unstable_erase tells you that it does not give any ordering guarantees. If “accidentally” the ordering is kept, there is no problem with the name to be used for all containers (and falling back to the exact behavior of the regular erase for some). This might mean that we don’t have the same complexity guarantees for all containers, but for a member function we need to specify the complexity per container anyway. What I’m saying is: I’m for a generic interface.

2) Is there a case where we want the stable and unstable guarantees for the same container at different places in the program? Otherwise we might just introduce a new container unstable_vector that never provides stability guarantees. Its erase function can just specify the fast complexity and use the swap-and-pop trick. Also with insert we can do something similar (we wouldn’t really need insert, but you know: the generic interface…). If we truly want to switch back and forth between the stability guarantees we could std::move from an unstable_vector to the regular vector and the other way around. Or we might introduce mutating views on these two vectors: If I take a stable view on the unstable_vector it gets sorted in place and calling erase on this view does the stable erase. And if I take an unstable view on the regular vector, erase will do the unstable erase. Maybe this is also just solved by *only* providing an unstable view to the vector. This whole discussion also has to be duplicated for inplace_vector (though we might be able to leverage the same unstable view; maybe even for deque).

Certainly, this all relies on the results of the performance benchmarks if we really need to go down this route.

> On May 23, 2026, at 2:51 PM, Xisheng Liu via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> 
> Hi Sebastian, Andre,
>
> Thank you both for raising this point.
>
> I can see the appeal of a fallback for generic code. It would make it easier to write code that says “erase this element, and I do not care about preserving order” without having to special-case every container.
>
> However, I am also a little concerned that a silent fallback to ordinary `erase` could make the meaning of `unstable_erase` less clear. My original motivation was not only to express that order need not be preserved, but also to expose the common vector-like optimization where allowing reordering reduces element relocation. If `unstable_erase` simply falls back to order-preserving `erase` for some containers, users may reasonably expect a relocation or complexity benefit that is not actually present.
>
> So I think this is an important design choice for the paper to discuss explicitly. One possible direction is:
>
> * provide `unstable_erase` only where the operation can provide a meaningful reduced-relocation or complexity benefit; or
> * provide a generic fallback for convenience, but make it clear that the fallback does not imply better complexity than ordinary `erase`.
>
> At the moment I am leaning toward keeping the initial proposal focused on the cases where the operation has a clear reduced-relocation or complexity motivation, but I agree that the generic-code use case should be mentioned and evaluated.
>
> Note: I previously posted under the name "Xiaoqing Tong(佟晓晴)". I will use my real name, Xisheng Liu, for future revisions of this proposal.
>
> Best regards,
> Xiaoqing Tong
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals