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