The poll result is here - meeting notes no longer online:   https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0365r0.pdf says:   P0041R0 Unstable remove algorithms Brent Friedman LEWG SG14: Billy Baker Mild consensus against proceeding   Further links:   https://quuxplusone.github.io/blog/2020/07/08/erase-if/ (by Arthur)   https://stackoverflow.com/questions/13818369/is-stability-of-stdremove-and-stdremove-if-design-fail   https://stackoverflow.com/questions/59525400/faster-erase-remove-idiom-when-i-dont-care-about-order-and-dont-have-duplicate   -----Ursprüngliche Nachricht----- Von:Arthur O‘Dwyer via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Do 30.01.2025 21:01 Betreff:Re: [std-proposals] Floating an idea: unstable_remove_if and friends An:std-proposals_at_[hidden]; CC:Arthur O‘Dwyer <arthur.j.odwyer_at_[hidden]>; On Thu, Jan 30, 2025 at 2:34 PM Ted Lyngmo via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: Hi! I have an idea for a set of "unstable" erase/remove algorithms that will move at most as many elements for which the predicate returns true.  https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0041r0.html "Unstable remove algorithms" (2015). I know this was in front of SG14 many years ago, but I don't know what happened to it; it predates the modern GitHub-issue workflow for tracking papers (https://wg21.link/p0041/github is a 404). Personally, I think it would be plausible to revive — I doubt it failed for any particular technical reason.  You might like to compare/contrast your https://github.com/TedLyngmo/liblyncpp/blob/main/include/lyn/algorithm.hpp with https://github.com/Quuxplusone/SG14/blob/master/include/sg14/algorithm_ext.h#L68-L130  –Arthur -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals