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@lists.isocpp.org>
Gesendet: Do 30.01.2025 21:01
Betreff: Re: [std-proposals] Floating an idea: unstable_remove_if and friends
An: std-proposals@lists.isocpp.org;
CC: Arthur O‘Dwyer <arthur.j.odwyer@gmail.com>;

On Thu, Jan 30, 2025 at 2:34 PM Ted Lyngmo via Std-Proposals <std-proposals@lists.isocpp.org> 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@lists.isocpp.org
 https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals