[libc++] self-defined function named 'print' may cause failure in overload resolution

[Yuzhiy05]

The following function will result in overload resolution failure

#include <iostream>
#include <unordered_map>
void print(auto const comment, auto const& map)
{
    std::cout << comment << "{";
    for (const auto &pair : map)
        std::cout << "{" << pair.first << ": " << pair.second << "}";
    std::cout << "}\n";
}
 
int main()
{
    std::unordered_map<char, int> map{{'a', 27}, {'b', 3}, {'c', 1}};
 
    print("map", map);
 
}

result

<source>:16:5: error: call to 'print' is ambiguous
   16 |     print("map", map);
      |     ^~~~~
<source>:4:6: note: candidate function [with comment:auto = const char *, map:auto = std::unordered_map<char, int>]
    4 | void print(auto const comment, auto const& map)
      |      ^
/opt/compiler-explorer/clang-trunk-20240924/bin/../include/c++/v1/print:341:28: note: candidate function [with _Args = <std::unordered_map<char, int> &>]
  341 | _LIBCPP_HIDE_FROM_ABI void print(format_string<_Args...> __fmt, _Args&&... __args) {
      |                            ^
1 error generated.

options

-std=c++26   -stdlib=libc++

godbolt

The C++ standard documentation requires that ostream support the inclusion of a std::print(std::ostream&...) , However, libc++ instead includes a complete print header , such as std::print(format_string<_Args...> __fmt, _Args&&... __args), then ADL might cause confusion

I do not want to include the header print, but including iostream might implicitly involve it

[frederick-vs-ja]

This is conforming. The standard allows <ostream> to include the whole <print>. Anyway, you should write ::print("map", map); to avoid potential ambiguity.

According to the current design, the print function family in <ostream> reuses most things in <print>, except for the FILE*-oriented standard overloads (see <__ostream/print.h> and <print>). I'm not sure whether it would be worthwhile to granularize <print>.

CC @philnik777 @mordante.

[philnik777]

I don't think we want to granularize <print> for this. If there is an include time benefit to this we can look into it, but I don't think it makes a ton of sense to try and fix stuff that will almost certainly break again at some point.