Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[temp.friend] p5 Two declarations correspond can ignore the return types #4945

Open
xmh0511 opened this issue Sep 27, 2021 · 2 comments
Open

Comments

@xmh0511
Copy link
Contributor

xmh0511 commented Sep 27, 2021

[temp.friend] p5 says

A template friend declaration may declare a member of a dependent type to be a friend. The friend declaration shall declare a function or specify a type with an elaborated-type-specifier, in either case with a nested-name-specifier ending with a simple-template-id, C, whose template-name names a class template. The template parameters of the template friend declaration shall be deducible from C ([temp.deduct.type]). In this case, a member of a specialization S of the class template is a friend of the class granting friendship if deduction of the template parameters of C from S succeeds, and substituting the deduced template arguments into the friend declaration produces a declaration that corresponds to the member of the specialization.

Consider a simplified example from the formal example that follows [temp.friend] p5

template<class T> struct A {
  void f();
};
template<> struct A<int> {
  int f();
};
class C {
    template<class T> friend void A<T>::f();  // #1
    int c;
};
int A<int>::f(){  // #2
    C c;
    return 0;
}
int main(){

}

A<T> at #1 can be deduced from A<int> at #2, substitute the deduced template arguments into the friend declaration produce void A<int>::f();, whereas the member of the specialization is int A<int>::f();, according to [basic.scope#scope-3.3.1]

Two declarations correspond if they (re)introduce the same name, both declare constructors, or both declare destructors, unless

  • [...]
  • each declares a function or function template, except when
  • both declare functions with the same parameter-type-list,21 equivalent ([temp.over.link]) trailing requires-clauses (if any, except as specified in [temp.friend]), and, if both are non-static members, the same cv-qualifiers (if any) and ref-qualifier (if both have one), or
  • both declare function templates with equivalent parameter-type-lists, return types (if any), template-heads, and trailing requires-clauses (if any), and, if both are non-static members, the same cv-qualifiers (if any) and ref-qualifier (if both have one).

In this case, both declarations do not declare function templates, the variance of the return types of such two declarations is not considered when determining whether they correspond or not.

Should we say that?

substituting the deduced template arguments into the friend declaration produces a valid declaration that corresponds to the member of the specialization

Since [basic.link] p11 requires that any two declarations of an Entity shall have the same type. In this case, substitute int into #1 will cause an invalid declaration.

@opensdh @jensmaurer

@jensmaurer
Copy link
Member

@opensdh, is there a problem here that "corresponds" doesn't actually compare the function return type? Should we augment the comparison accordingly?

@opensdh
Copy link
Contributor

opensdh commented Dec 21, 2021

It’s deliberate that “corresponds” ignores return types, so that

void f();
int f();

declare one function (invalidly). (This approach works well across translation units since we need some means of recognizing when they might mangle the same way.)

In general, we do rely on [basic.link]/11 to reject “corresponds but…” cases, but that doesn’t apply well here because we describe this in terms of a substitution that might or might not actually be “processed” as a declaration. We should probably check the return types explicitly; it might be good to introduce a term for “corresponds and…”, which would largely reconstitute the prior usage of “would be a well-formed redeclaration of”.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants