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

[dcl.fct]/22 An abbreviated function template is _functionally_ equivalent to a function template #5495

Open
dfrib opened this issue May 26, 2022 · 5 comments

Comments

@dfrib
Copy link

dfrib commented May 26, 2022

Problems with the presentation of the specification, which, when fixed, would not alter the (intended) meaning of the specification. Typos and obvious inconsistencies fall into this category.

I think this can be fixed as an editorial issue, but please advice me otherwise.


I believe that [dcl.fct]/22, when describing the equivalence relation between an abbreviated function template and a function template [emphasis mine]

An abbreviated function template is a function declaration that has one or more generic parameter type placeholders ([dcl.spec.auto]). An abbreviated function template is equivalent to a function template ([temp.fct]) [...]

should in fact be

[...] is functionally equivalent [...]

and that this is the intended meaning of the specification:

  • The non-normative example of [dcl.fct]/22 uses functional equivalence:

    [...] The declarations above are functionally equivalent (but not equivalent) to their respective declarations below [...]

  • P0717R1 discussed Concept TS's terse template syntax, with a Kona (15 | 14 | 13 | 2 | 3) vote to restrict redeclarations to identical forms (equivalence). P1141R2 later introduced abbreviated function templates with the specification cited above, and it seems just as an oversight that "functional equivalence" didn't make the normative spec, particularly as both authors of P07017R1 were co-authors of P1141R2.
@xmh0511
Copy link
Contributor

xmh0511 commented May 27, 2022

The first "equivalent" means we can use the abbreviate function template in most respects as an ordinary function template. Such as explicitly specifying the specialization fun<T>(). The concept of the functionally equivalent is defined in [temp.over.link]. The comment is just a concise way to expose what "equivalent" means(i.e. expose-only). If we declare the abbreviate function template and the functionally equivalent function template in a program, it violates [temp.over.link] p7, I think.

The invented function template is used to depict what the synthesized declaration of the abbreviated function template looks like, such that we can explicitly specialize it or do anything identical to what can be done on a function template, without copying [temp] for it. If they were functionally equivalent, these points are not guaranteed. I agree we do not have a formal rule specifying what the comment says(i.e. functionally equivalent to the grammatical function template). We might just append a rule:

A function template declaration that corresponds to the function template declaration associated with an abbreviated function template is functionally equivalent to the abbreviated function template.

void g1(const auto*);

template<class T>
int g1(const T*);

such two function templates are neither equivalent nor functionally equivalent. As a contrast

void g1(const auto*);

template<class T>
void g1(const T*);

they are functionally equivalent, the program is ill-formed; no diagnostic required.

@dfrib
Copy link
Author

dfrib commented May 27, 2022

I agree we do not have a formal rule specifying what the comment says(i.e. functionally equivalent to the grammatical function template). We might just append a rule:

A function template declaration that corresponds to the function template declaration associated with an abbreviated function template is functionally equivalent to the abbreviated function template.

Is "what you can do with" a function template declared as an abbreviated function template really something that needs to be covered under "equivalence"? Will it not be suffice with "functional equivalence", whilst then reserving [temp.over.link]/7 and IFNDR for the case of conflicting declarations?

As a contrast

void g1(const auto*);

template<class T>
void g1(const T*);

they are functionally equivalent, the program is ill-formed; no diagnostic required.

With the current normative wording this program is not IFNDR (although I think it was intended to be), and we see compiler variance here where Clang seems to accept (although NDR...) abbreviated function template declarations as equivalent to (matching) function template declarations, whereas GCC does not (DEMO).

@xmh0511
Copy link
Contributor

xmh0511 commented May 27, 2022

Will it not be suffice with "functional equivalence"

Not sufficient. We expect the "synthesized" declaration for the abbreviated function template is identical to what we said in the rule. Consider this example:

template<int N>
struct C{};
template<int N>
void fun(auto *, C<N>);

/*
template<int N, class T>
void fun(T*, C<N>); // #2
*/

we expect the synthesized declaration of the abbreviated function template like the one at #2, anything could be determined. If we say "functionally equivalent" to #2, that means you could have an infinitely possible declaration, such as

template<int N, class T>
void fun(T*, C<N + 1 - 1>); // #2

you can never explicitly specialize it like template<> void fun(int*, C<10>) because you never know which one the implementation would choose.

the program is ill-formed; no diagnostic required.

This means the document impose no requirement on the implementations, in other words, they can do whatever they want. See [temp.over.link] p8.

@frederick-vs-ja
Copy link
Contributor

This issue seems a duplicate of #4121.

@CaseyCarter
Copy link
Contributor

This issue seems a duplicate of #4121.

I think you mean "This issue is functionally equivalent to #4121".

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

4 participants