On 5/23/26 04:20, 佟晓晴 via Std-Proposals wrote:
> Hello,
>
> I would like to propose a small standard library extension for std::vector:
> std::unstable_erase and std::unstable_erase_if.
>
> The motivation is to standardize the common swap-and-pop idiom used when
> removing elements from a vector where the relative order of the remaining
> elements is not semantically important.
>
> C++20 provides std::erase and std::erase_if for standard containers. For
> std::vector, these operations preserve the relative order of the remaining
> elements. In performance-sensitive code, such as games, simulations, servers,
> and dense object storage, preserving order can impose unnecessary relocation
> costs.
>
> The proposed interface is:
>
> template<class T, class Alloc, class U>
> constexpr typename std::vector<T, Alloc>::size_type
> unstable_erase(std::vector<T, Alloc>& c, const U& value);
>
> template<class T, class Alloc, class Pred>
> constexpr typename std::vector<T, Alloc>::size_type
> unstable_erase_if(std::vector<T, Alloc>& c, Pred pred);
>
> The operation removes matching elements but does not preserve the order of
> the remaining elements. It is intended as an unstable counterpart to
> std::erase / std::erase_if for std::vector, not as a replacement for them.

Sounds like a useful thing.

Where did P0041 go? It's not in the Working Draft.

> A public draft paper, prototype implementation, and preliminary benchmark
> results are available here:
>
> https://github.com/BaiJin0224/unstable-erase <https://github.com/BaiJin0224/unstable-erase>
>
> I would appreciate feedback on the following points:
>
> 1. Whether this is a reasonable container-level facility for std::vector.

I think we want this for all of std::vector, std::inplace_vector, and
std::deque. Also, the narrative could benefit from a comparison against
std::hive (an entire container where relative order is not preserved).

> 2. Whether the names unstable_erase and unstable_erase_if are appropriate.

Sounds fine to me.

> 3. Whether the initial scope should remain limited to std::vector.

I don't think so.

> 4. Whether the wording should specify a swap-and-pop-like complexity model.

Of course, otherwise there is no point in having this special thing.

> 5. How exception safety should be specified.

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?

Jens