https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107850
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Charles-Henri Gros from comment #4) > Looking into it further, there may be an implicit requirement that the > predicate does not modify its argument. > https://eel.is/c++draft/algorithms.requirements#6 See paragraph 4. That only applies to the Algorithms clause, not the Containers clause. So it doesn't apply to std::erase_if for maps. It *does* apply to std::erase_if for sequence containers, because those are defined in terms of std::remove_if, which is defined in the Algorithms clause. It doesn't apply to std::erase_if for sets, but *first is always const for those anyway so it's irrelevant. > I'm unfortunately not well-versed enough in C++ legalese to tell what > "possibly const" means in that context, A "glvalue u of type (possibly const) T" means u is a T& or const T&. Your predicate would fail that requirement (if it applied here) because it cannot be called with const T& at all, so pred(u) isn't a valid expression. > nor "apply any non-constant function". It means you can't modify the argument. > And while I understand that a "predicate" is generally meant to not do > modification, there are fairly frequent use cases for "apply this > potentially modifying operation, and depending on its result remove the > element from the container". You can write your own "modify and remove if" algo for that. > And in practice, this works (e.g. > std::remove_if, your own earlier version of erase_if, other compilers' > version...). It's undefined behaviour to do that with std::remove_if. > Maybe I should go to LEWG and lobby to remove that limitation. In the > meanwhile, I'll probably just keep my own, perhaps slightly less optimal > removal algorithms. There is no such restriction on std::erase_if for maps today, but I'll be lobbying the committee to *add* it!
