|| 的无关可见过载防止|| 从要求子句中的短路

Question

Cppreference says:

Disjunctions are evaluated left to right and short-circuited (if the left constraint is satisfied, template argument substitution into the right constraint is not attempted).

This appears to be correct, because following code compiles:

template <typename T>
struct A
{
    static constexpr bool value = T::value;
};

template <typename T>
void foo() requires (sizeof(T) == 1) || A<T>::value {}

int main()
{
    foo<char>();
}

Even though A<char>::value is ill-formed, there's no error because it's short-circuited away.

But if I add an unrelated overload of operator|| , it stops working:

struct Dummy {};
bool operator||(Dummy, Dummy) {return true;}

template <typename T>
struct A
{
    static constexpr bool value = T::value;
};

template <typename T>
void foo() requires (sizeof(T) == 1) || A<T>::value {}

int main()
{
    foo<char>();
}

Run on gcc.godbolt.org

Now Clang (10.0.0) starts to complain:

<source>:7:35: error: type 'char' cannot be used prior to '::' because it has no members
    static constexpr bool value = T::value;
                                  ^
<source>:11:47: note: in instantiation of static data member 'A<char>::value' requested here
void foo() requires (sizeof(T) == 1) || A<T>::value {}
                                              ^
<source>:11:21: note: while substituting template arguments into constraint expression here
void foo() requires (sizeof(T) == 1) || A<T>::value {}
                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<source>:15:5: note: while checking constraint satisfaction for template 'foo<char>' required here
    foo<char>();
    ^~~
<source>:15:5: note: in instantiation of function template specialization 'foo<char>' requested here

GCC (trunk) has no problem with this code.

If operator|| is in a namespace (and there's no using namespace ), the code works.

Is it a Clang bug? Are there any workarounds, other than not having visible overloads of ||?

Answer 1

This bug was fixed , so the short-circuiting will work properly in Clang 11.