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).
