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