[C++] Lookup for implicitly declared copy-assignment fails when function call syntax is used in template classes

[TheCalligrapher]

For the following code

template <typename = int> struct C
{
  C &foo(const C &c) { return operator =(c); }
};
 
int main()
{
  C<> c;
  c.foo(c);
}

Clang will generate a diagnostic

error: explicit qualification required to use member 'operator=' from dependent base class
    3 |   C &foo(const C &c) { return operator =(c); }
      |                

The code appears to be perfectly valid, yet it is rejected by Clang. The above diagnostic mentions "base class", although obviously there's no inheritance of any kind in this code.

Prepending the call to copy-assigment with this->

C &foo(const C &c) { return this->operator =(c); }

solves the problem (which incidentally is how one solves the "lookup in a dependent base class" issues).

Switching from functional notation to operator-in-expression notation makes the error to go away

C &foo(const C &c) { return *this = c; }

Trying to qualify the call

C &foo(const C &c) { return C::operator =(c); }

results in

error: no member named 'operator=' in 'C<type-parameter-0-0>'
    3 |   C &foo(const C &c) { return C::operator =(c); }
      |        

Also, adding an explicit declaration of the copy-assigment operator

C &operator =(const C &) = default;

solves the issue as well.

With non-template classes the issue does not manifest itself.

The diagnostic implies that when functional notation is used to refer to the implicitly declared copy-assignment operator in a template class (from within a member definition), name lookup fails for some unknown reason, and the compiler immediately jumps to conclusion that it is a "lookup in a dependent base class" issue. It obviously is not.

Anyway, is this a known issue? Or am I missing some peculiarity of name lookup in template classes?

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: AndreyT (TheCalligrapher)

For the following code

template <typename = int> struct C
{
  C &foo(const C &c) { return operator =(c); }
};
 
int main()
{
  C<> c;
  c.foo(c);
}

Clang will generate a diagnostic

error: explicit qualification required to use member 'operator=' from dependent base class
    3 |   C &foo(const C &c) { return operator =(c); }
      |                

The code appears to be perfectly valid, yet it is rejected by Clang. The above diagnostic mentions "base class", although obviously there's no inheritance of any kind in this code.

Prepending the call to copy-assigment with this->

C &foo(const C &c) { return this->operator =(c); }

solves the problem (which incidentally is how one solves the "lookup in a dependent base class" issues).

Also, switching from functional notation to operator-in-expression notation makes the error to go away

C &foo(const C &c) { return *this = c; }

Trying to qualify the call

C &foo(const C &c) { return C::operator =(c); }

results in

error: no member named 'operator=' in 'C<type-parameter-0-0>'
    3 |   C &foo(const C &c) { return C::operator =(c); }
      |        

With non-template classes the issue does not manifest itself.

The diagnostic implies that when functional notation is used to refer to the implicitly declared copy-assignment operator in a template class (from within a member definition), name lookup fails for some unknown reason, and the compiler immediately jumps to conclusion that it is a "lookup in a dependent base class" issue. It obviously is not.

Anyway, is this a known issue? Or am I missing some peculiarity of name lookup in template classes?

[zygoloid]

This is a peculiarity of name lookup in class templates. See https://eel.is/c++draft/temp.dep.general#2.5

The problem is that we don't know whether the class has a member named operator= in general until instantiation. So we don't know what the result of unqualified lookup should be.

But the diagnostic is definitely bad and we should fix that!

[TheCalligrapher]

And?

The linked wording defines a call to operator = as a dependent call. Dependent names are looked up in accordance with a different set of rules, but they are still supposed to be looked up. Why does this lookup for unqualified operator = fail in this case?

Dependent call simply means that the lookup should be postponed till so called "second phase", i.e. looked up at the moment of instantiation. So, how come Clang does not find it? I don't see any "peculiarity" for that.

[zygoloid]

Yeah, I agree that the standard seems to suggest that this is supposed to work, but it's not completely clear how.

The lookup is being postponed -- Clang accepts the template definition, and only rejects during the instantiation. During instantiation, ADL is performed (and finds nothing useful), but unqualified lookup is only ever performed in the template definition context, and in the template definition context, no operator= can be found.

Probably the best thing we could do would be, if we try to instantiate an UnqualifiedLookupExpr naming operator=, perform class member lookup into the type of *this.

[TheCalligrapher]

Also, it is not clear to me what you mean by "the problem is that we don't know whether the class has a member named operator= in general until instantiation".

A class always has such a member. No way around it. Each and every class always unconditionally includes a declaration of a copy assignment operator. If the user does not declare one explicitly, the compiler is required to declare one implicitly: https://eel.is/c++draft/class.copy.assign#2

The copy assignment might be defined as deleted, but that bears no relevance to the matter at hand, since we are talking exclusively about name lookup. Name lookup is not affected by definitions. A name declared as deleted is still declared and is still perfectly visible to name lookup.

If I'm not missing anything, the only template-specific name-lookup-related thing about copy assignment operator is the exact argument type: it is either X& X::operator=(const X&) or X& X::operator=(X&) and that might depend on template parameters. This "to const or not to const" dilemma is why we might have to postpone the lookup to the second phase.

(BTW, the wording you linked is ultra-new. Even something as fresh as C++20 does not have it. Is it still supposed to be present in older standards in some other form? And if not, why has it appeared only now? Is there a proposal or DR which triggered this change?)