[Bug libstdc++/59508] std::find could use specialized container's find

["redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- 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, where
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 pair
of iterators).