From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id A1A443858CDB; Mon,  8 Jan 2024 10:58:03 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A1A443858CDB
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1704711483;
	bh=qlDwNNh4QJzr0Ky9aqBGnBgQIz6W7Y3FdX+Pfaxcs2o=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=HDWfZkLPhK5MoFN4xpUAycy8vgZlKQeh0LkXDNn44DulL020xjc1MXK2m6AzHg0qY
	 X8tejbzMn782y7cT1CDSG2DF9EM9wVt4zvSFyGwUeQCqjP6DKPLfI+2iZfPaBnSD5C
	 ynvgmKlbm9yUHnb6qb7SUwjRzay3R3fznGftELZ4=
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/59508] std::find could use specialized container's
 find
Date: Mon, 08 Jan 2024 10:58:01 +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: 4.9.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-59508-4-k1bNwIIYK1@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59508-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59508-4@http.gcc.gnu.org/bugzilla/>
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: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D59508

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #6)
> Right.  If, then std::find should not invoke std::set::find (or
> std::map::find etc) but the library's internal function to search the rb
> tree.

If that internal function exists, then it means the specialization is using=
 the
primary template, and in that case we could just use std::set::find anyway.

> Of course users might still provide specializations of std::find for
> particular iterator types but that shouldn't be a problem I think.

That's not allowed since C++20.

FWIW we already optimize std::distance this way for std::list iterators, wh=
ere
it's possible to obtain the container from the iterator. But I don't think
we're likely to do this for other containers and std::find. I'm inclined to
close this as WONTFIX.

Anyway, if we did do this for std::find we should do it for ranges::find, at
least when a container is passed directly to ranges::find (rather than a pa=
ir
of iterators).=