From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 2D4D23858D1E; Tue, 29 Nov 2022 11:06:04 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2D4D23858D1E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1669719964; bh=r72RndVZ2WqElanVEEEff8YUFZmJLjRjqCcqLzmDHX8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=etLr9ECQUoaB/2qAgo0lFKxQx4TmBDzBq/zxDL/XorwRo6QEtXeV47muNyNf48XMO l/ab9JI8nxblhWnXmg+xAWTNar6LY4btgQR552CdWYblfUpO79gEqJQh0pN3yXZ64L wkUVHEJ7EFCLGwHcu3Jc50ol9NhjBoIt4dFFG+fs= From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/107850] [12 Regression] std::erase_if (map) forces predicate to takes a const value_type Date: Tue, 29 Nov 2022 11:06:02 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 12.1.0 X-Bugzilla-Keywords: rejects-valid X-Bugzilla-Severity: normal X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: redi at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107850 --- Comment #5 from Jonathan Wakely --- (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 Contai= ners 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 canno= t 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!=