Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Ambiguous resolution with template conversion operator

I had to do a similar code:

#include <type_traits>

template<typename S>
struct probe {
    template<typename T, typename U = S, std::enable_if_t<
        std::is_same<T&, U>::value &&
        !std::is_const<T>::value, int> = 0>
    operator T& () const;

    template<typename T, typename U = S&&, std::enable_if_t<
        std::is_same<T&&, U>::value &&
        !std::is_const<T>::value, int> = 0>
    operator T&& ();

    template<typename T, typename U = S, std::enable_if_t<
        std::is_same<T const&, U>::value, int> = 0>
    operator T const& () const;

    template<typename T, typename U = S&&, std::enable_if_t<
        std::is_same<T const&&, U>::value, int> = 0>
    operator T const&& () const;
};

struct some_type {};
struct other_type {};

auto test_call(some_type const&, other_type) -> std::false_type;
auto test_call(some_type&, other_type) -> std::true_type;

int main() {
    static_assert(decltype(test_call(probe<some_type&>{}, other_type{}))::value, "");
}

It works under GCC and Clang, but it doesn't compile on visual studio, with an ambiguous resolution error. Which compiler is wrong and why?

GCC and Clang, Visual studio

Here's the msvc output:

source_file.cpp(31): error C2668: 'test_call': ambiguous call to overloaded function
source_file.cpp(28): note: could be 'std::true_type test_call(some_type &,other_type)'
source_file.cpp(27): note: or       'std::false_type test_call(const some_type &,other_type)'
source_file.cpp(31): note: while trying to match the argument list '(probe<some_type &>, other_type)'
source_file.cpp(31): error C2651: 'unknown-type': left of '::' must be a class, struct or union
source_file.cpp(31): error C2062: type 'unknown-type' unexpected
like image 465
Guillaume Racicot Avatar asked Jun 24 '18 20:06

Guillaume Racicot


1 Answers

The code can be reduced to the following:

#include <type_traits>

struct some_type {};

struct probe {
    template<typename T, std::enable_if_t<!std::is_const<T>::value, int> = 0>
    operator T& () const;
};

auto test_call(some_type const&) -> std::false_type;
auto test_call(some_type&) -> std::true_type;

int main() {
    static_assert(decltype(test_call(probe{}))::value, "");
}

According to [temp.deduct.conv]/5 & 6:

In general, the deduction process attempts to find template argument values that will make the deduced A identical to A. However, there are four cases that allow a difference:

  • If the original A is a reference type, A can be more cv-qualified than the deduced A (i.e., the type referred to by the reference)

  • ...

These alternatives are considered only if type deduction would otherwise fail. If they yield more than one possible deduced A, the type deduction fails.

T is deduced to be some_type for both function calls. Then according to [over.ics.rank]/3.3:

User-defined conversion sequence U1 is a better conversion sequence than another user-defined conversion sequence U2 if they contain the same user-defined conversion function or constructor or they initialize the same class in an aggregate initialization and in either case the second standard conversion sequence of U1 is better than the second standard conversion sequence of U2.

probe -> some_type& -> some_type& is better than probe -> some_type& -> const some_type&, so there is no ambiguity, GCC and Clang are right.


BTW, if we remove std::enable_if_t<...> part in the code above, MSVC and GCC fails while Clang compiles. For further analysis, I focus on the first test_all:

#include <type_traits>

struct some_type {};

struct probe {
    template<typename T>
    operator T& () const
    {
        static_assert(std::is_const_v<T>);
        static T t;
        return t;
    }
};

auto test_call(some_type const&) -> std::false_type;

int main() {
    test_call(probe{});
}

Then we find the static_assert fires only under Clang. That is to say, Clang deduces T to be some_type instead of const some_type. I think this is a bug of Clang.

like image 106
xskxzr Avatar answered Sep 24 '22 07:09

xskxzr