Ttykuu

Take following code as an example

#include <algorithm>

namespace baz 
 template<class T>
 void sort(T&&)


namespace boot 
 const auto sort = [](auto &&);


void foo ()
 using namespace std;
 using namespace baz;
 sort(1);


void bar()
 using namespace std;
 using namespace boot;
 sort(1);

I expected that since foo compiled, then bar shall compile as well. To my surprise, the foo compiles correctly and bar has problem with ambiguous call to sort function. Am I doing something illegal here or this is proper way compiler should behave? If so, why is it so different. I though generic lambda can be treated as syntactic sugar for generic function.

live example

Lambdas are no different than regular functors or even plain function pointers in this regard. Overload resolution is only considering as candidates actual functions that are named sort. In other words, overload resolution is not going to consider literally anything that has a function call operator. Only true functions.

#include <string>
#include<vector>
#include <algorithm>

namespace baz 

 template<class T>
 void sort(T&&)


namespace boot 
 const auto sort = [](auto &&);


namespace booot 
 struct sort_functor
 
 template<class T>
 void operator()(T&&)const;
 ;

 constexpr sort_functor sort;


namespace boooot

 void sort_func(int) 

 constexpr auto sort = &sort_func;


void foo ()
 using namespace std;
 using namespace baz;
 sort(1);


void bar()
 using namespace std;
 using namespace boot;
 sort(1);



void baar()
 using namespace std;
 using namespace booot;
 sort(1); // still an error



void baaar()
 using namespace std;
 using namespace boooot;
 sort(1); // still the exact same error

UPDATE: To answer Michael Kenzel's question below. Consider the function baar:

void baar()
 using namespace std;
 using namespace booot;
 // sort(1); is syntatic sugar for:
 sort.operator()(1);

Consider the expression sort.operator()(1). It actually consists of two operators. First the binary . operator is applied with operands sort and operator(). The result of this sub-expression is a true function type, and it is a prvalue. Although indeed it is a true function type, it is an rvalue and so it has no name. It is most definitely not named sort, so it cannot be considered for overload resolution of functions named sort.

The sole purpose of the prvalue function type resulting from expressions like:

some_instance.some_method
some_instance_ptr->some_method
(some_instance.*(&some_type::some_method))
(some_instance_ptr->*(&some_type::some_method))

is to have 1) be a true function type and therefore 2) have a function call operator.

So when a type has a user defined call operator and uses the sugary syntax, the call operator is not really being applied to the object, it is being applied to a true function type prvalue resulting from an expression like above.

The problem here is not that the call to sort is ambiguous, but that the name sort is ambiguous. Name lookup happens before overload resolution.

I believe the relevant section is [basic.lookup]/1, specifically

[…] The declarations found by name lookup shall either all denote the same entity or shall all denote functions or function templates; in the latter case, the declarations are said to form a set of overloaded functions ([over.load]). […]

In your case, the name sort denotes both, the object boot::sort as well as the set of overloaded functions std::sort. Therefore, name lookup fails.

Your code is not different from if you had written, for example

namespace baz 
 int a;


namespace boot 
 int a;


void foo() 
 using namespace baz;
 using namespace boot;
 a = 42; // error: reference to 'a' is ambiguous

Try it out here, note how the error message is the same as in your case, specifically referring to the name itself being ambiguous rather than the function call.