[Clang] operator== rewrite return type restriction is overly strict

[ednolan]

over.match.oper states: "If a rewritten operator== candidate is selected by overload resolution for an operator @, its return type shall be cv bool."

Presumably based on that language, Clang rejects the following code:

struct foo {};

template <typename T>
auto operator==(foo, T) { return true; }

void bar() {
    0 == foo{};
}

With this error:

<source>:7:7: error: return type 'auto' of selected 'operator==' function for rewritten '==' comparison is not 'bool'
    7 |     0 == foo{};
      |     ~ ^  ~~~~~
<source>:4:6: note: declared here
    4 | auto operator==(foo, T) { return true; }
      |      ^

However, GCC, MSVC and EDG all accept it, as shown in Compiler Explorer here: https://godbolt.org/z/46aaPvn46

I think Clang is being overly restrictive here. The fact that the operator== returns auto doesn't violate that "its return type shall be cv bool," since auto is a placeholder for a return type, not a return type itself. The standard seems to make this distinction in dcl.spec.auto:

A placeholder type can appear with a function declarator in the decl-specifier-seq, type-specifier-seq, conversion-function-id, or trailing-return-type, in any context where such a declarator is valid. If the function declarator includes a trailing-return-type ([dcl.fct]), that trailing-return-type specifies the declared return type of the function. Otherwise, the function declarator shall declare a function. If the declared return type of the function contains a placeholder type, the return type of the function is deduced from non-discarded return statements, if any, in the body of the function ([stmt.if]).

Notice the distinction between "declared return type" (which is auto or decltype(auto)) and "return type" (which is "deduced from non-discarded return statements [...] in the body of the function").

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Edward Nolan (ednolan)

[over.match.oper](https://eel.is/c++draft/over.match.oper#10) states: "If a rewritten operator== candidate is selected by overload resolution for an operator @, its return type shall be cv bool."

Presumably based on that language, Clang rejects the following code:

struct foo {};

template <typename T>
auto operator==(foo, T) { return true; }

void bar() {
    0 == foo{};
}

With this error:

<source>:7:7: error: return type 'auto' of selected 'operator==' function for rewritten '==' comparison is not 'bool'
    7 |     0 == foo{};
      |     ~ ^  ~~~~~
<source>:4:6: note: declared here
    4 | auto operator==(foo, T) { return true; }
      |      ^

However, GCC, MSVC and EDG all accept it, as shown in Compiler Explorer here: https://godbolt.org/z/46aaPvn46

I think Clang is being overly restrictive here. The fact that the operator== returns auto doesn't violate that "its return type shall be cv bool," since auto is a placeholder for a return type, not a return type itself. The standard seems to make this distinction in dcl.spec.auto:

> A placeholder type can appear with a function declarator in the decl-specifier-seq, type-specifier-seq, conversion-function-id, or trailing-return-type, in any context where such a declarator is valid. If the function declarator includes a trailing-return-type ([dcl.fct]), that trailing-return-type specifies the declared return type of the function. Otherwise, the function declarator shall declare a function. If the declared return type of the function contains a placeholder type, the return type of the function is deduced from non-discarded return statements, if any, in the body of the function ([stmt.if]).

Notice the distinction between "declared return type" (which is auto or decltype(auto)) and "return type" (which is "deduced from non-discarded return statements [...] in the body of the function").

[pinskia]

This should also be accepted:

struct foo {};

template <typename T>
auto operator==(foo, T) { return (T)true; }

void bar() {
    false == foo{};
}

While this should be rejected:

struct foo {};

template <typename T>
auto operator==(foo, T) { return (T)true; }

void bar() {
    0 == foo{};
}

It is interesting if we replace auto with T, clang accepts the first example here and the warns about the return type on the second example (GCC rejects the second example in both the auto and T case).

[shafik]

Clang looks wrong here, I looked at the other locations we use return type shall be and I don't think the intent is that it has be to explicit spelt out.

[eisenwave]

Another repro: https://stackoverflow.com/questions/78339664/clang-fails-to-instantiate-operator-from-operator-with-auto-return/78355975

template <typename T>
struct Wrapper {
    T value;
    constexpr auto operator==(const T other) const {
        return value == other;
    }
};

template <Wrapper W>
void fun() {
    static_assert(W != 0); // This line fails on Clang
}

int main() {
    fun<Wrapper{1}>();
}

<source>:11:21: error: return type 'auto' of selected 'operator==' function for rewritten '!=' comparison is not 'bool'
   11 |     static_assert(W != 0); // This line fails on Clang
      |                   ~ ^  ~
<source>:15:5: note: in instantiation of function template specialization 'fun<Wrapper<int>{1}>' requested here
   15 |     fun<Wrapper{1}>();
      |     ^
<source>:4:20: note: declared here
    4 |     constexpr auto operator==(const T other) const {
      |  

[TymianekPL]

The following code compiles just fine:

struct C{};

template <typename T>
constexpr auto operator==(bool, const T)  { return true; }

template <typename T>
constexpr auto operator==(const T, bool) { return true; }

int main(void)
{
	C c{};
	static_assert(c == true);
	static_assert(true == c);
	return 0;
}

I suppose it is related to the argument order, and because the original operator has a return type of a placeholder type, it does not take it into consideration at first. I might be wrong on this one, but I presume that this is a qualified name lookup bug.

[zygoloid]

Based on https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1630r1.html#proposal-1 it seems like the intent of the rule (that you don't perform rewrites on operators that might not be intended to support them) might be better achieved by not performing rewrites unless the declared return type is bool (not auto) -- an operator== with multiple different possible return types presumably doesn't intend to support rewrites. However, the actual rule as written does allow rewrites for a deduced return type that deduces to bool.

I think the issue is that we're not triggering return type deduction before checking whether the return type of the operator== is bool. For example, we reject this:

struct C { template<typename T = bool> auto operator==(T) { return true; } } c;
bool x = true == c;
bool y = c == true;

... but accept if the order of x and y is reversed, because we'll trigger return type deduction for C::operator==<bool> when checking the initializer of y. Seems like we just need to call Sema::DeduceReturnType before doing the check.