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.

Sign up for GitHub

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

Jump to bottom

[temp.explicit] Note disallows explicit instantiation of non-template member functions of a class template specialization #5110

Open
zygoloid opened this issue Nov 17, 2021 · 2 comments
Open

[temp.explicit] Note disallows explicit instantiation of non-template member functions of a class template specialization #5110

zygoloid opened this issue Nov 17, 2021 · 2 comments
Labels
cwg Issue must be reviewed by CWG. not-editorial Issue is not deemed editorial; the editorial issue is kept open for tracking.

Comments

@zygoloid
Copy link
Member

[temp.explicit]/4:

[...] If the explicit instantiation is for a function or member function, the unqualified-id in the declarator shall be either a template-id or, where all template arguments can be deduced, a template-name or operator-function-id.
[Note 1: The declaration can declare a qualified-id, in which case the unqualified-id of the qualified-id must be a template-id. —end note]

I don't know what this note is trying to say, but it appears to flat-out contract the previous normative sentence that allows the unqualified-id to be a template-name or operator-function-id.

But I think both the note and the normative sentence here are nonsense. Consider the immediately following sentence:

If the explicit instantiation is for a member function, a member class or a static data member of a class template specialization, the name of the class template specialization in the qualified-id for the member name shall be a simple-template-id.

So if the explicit instantiation is for a member function of a class template specialization, then we are required to have Class<args>::Function<more args>, even if the function is a non-template member function? What?

I think we meant something more like:

[temp.explicit]/4:

If the explicit instantiation is for a class or member class, the elaborated-type-specifier in the declaration shall include a simple-template-id; otherwise, the declaration shall be a simple-declaration whose init-declarator-list comprises a single init-declarator that does not have an initializer. If the explicit instantiation is for a function or member function template specialization, the unqualified-id in the declarator shall be either a template-id or, where all template arguments can be deduced, a template-name or operator-function-id.
[Note 1: The declaration can declare a qualified-id, in which case the unqualified-id of the qualified-id must be a template-id. —end note]
If the explicit instantiation is for a member function, a member class or a static data member of a class template specialization, the name of the class template specialization in the qualified-id for the member name shall be a simple-template-id. If the explicit instantiation is for a variable template specialization, the unqualified-id in the declarator shall be a simple-template-id. An explicit instantiation shall appear in an enclosing namespace of its template. If the name declared in the explicit instantiation is an unqualified name, the explicit instantiation shall appear in the namespace where its template is declared or, if that namespace is inline (9.8.2), any namespace from its enclosing namespace set.

... but this is still wrong, given that it doesn't properly handle a member of a member of a class template specialization. (The above also loses the restriction that you can't explicitly instantiate an untemplated function.)
@jensmaurer
Copy link
Member

Do we want to retain the gist of the note by adding "(possibly appearing in a qualified-id)" after "unqualified-id in the declarator"?

(The above also loses the restriction that you can't explicitly instantiate an untemplated function.)

I'm not seeing the updated text to change anything in that regard, if we assume that a "function template specialization" only exists for a function template.

I'm also wondering whether the quoted text has the logic backward: It should derive the entity to be instantiated from the syntax used, but it's establishing syntax restrictions based on divining the programmer's intent ("If the explicit instantiation is for X...": how do we know it's "for X"?)

@jensmaurer jensmaurer added the decision-required A decision of the editorial group (or the Project Editor) is required. label Nov 17, 2021
@tkoeppe tkoeppe added cwg Issue must be reviewed by CWG. and removed decision-required A decision of the editorial group (or the Project Editor) is required. labels Jun 12, 2023
@tkoeppe
Copy link
Contributor

tkoeppe commented Jun 12, 2023

Editorial meeting decision: this is not editorial. There clearly is an issue here, but it's best for Core to take a look.

@jensmaurer jensmaurer added the not-editorial Issue is not deemed editorial; the editorial issue is kept open for tracking. label Jun 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
cwg Issue must be reviewed by CWG. not-editorial Issue is not deemed editorial; the editorial issue is kept open for tracking.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@zygoloid @tkoeppe @jensmaurer