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.res.general] p5: dependent names in other than type-only context #4792

Open
xmh0511 opened this issue Aug 4, 2021 · 6 comments
Open

[temp.res.general] p5: dependent names in other than type-only context #4792

xmh0511 opened this issue Aug 4, 2021 · 6 comments

Comments

@xmh0511
Copy link
Contributor

xmh0511 commented Aug 4, 2021 •
edited

Consider the first sentence in [temp.res#general-5]

A qualified-id whose terminal name is dependent and that is in a type-only context is considered to denote a type.

How about the otherwise case? if the terminal name is not in a type-only context, whether it may denote a type or it definitely does not denote a type? It's difficult to infer the meaning of the otherwise cases from the current sentence.

Is it more clear if we change it to that

A qualified-id whose terminal name is dependent is considered to denote a type if and only if its terminal name is in a type-only context.

In this sentence, the subtext means the qualified-id can never denote a type if the dependent terminal name is not in a type-only context. This subtext also conforms to the intent of the standard.
@jensmaurer
Copy link
Member

I think we mean that the qualified-id needs to be in a type-only context, not just its terminal name. Any rephrasing should retain that meaning.

@jensmaurer jensmaurer added the changes requested Changes to the wording or approach have been requested and not yet applied. label Aug 4, 2021
@xmh0511
Copy link
Contributor Author

xmh0511 commented Aug 4, 2021 •
edited

However, [temp.res#general-4] is saying so, that is

A qualified or unqualified name is said to be in a type-only context if it is the terminal name of

  • [...]

In other words, the qualified or unqualified name first refers to the terminal name of something and we say they are in a type-only context if the terminal name(qualified or unqualified name) satisfies some conditions. The meaning is more clear in [basic.lookup.qual#general-2]. On another hand, if a terminal name of something is in that context, of course, the something that comprises the name is also in that context.

@jensmaurer jensmaurer removed the changes requested Changes to the wording or approach have been requested and not yet applied. label Aug 4, 2021
@jensmaurer
Copy link
Member

jensmaurer commented Aug 4, 2021 •
edited

@opensdh, regarding [temp.res.general] p4:

I think it doesn't make sense to claim that a terminal name can be qualified; the rules for "terminal name" would kill any qualification. If you agree, p4 should just say "A name is said to be in a type-only context if it is the terminal name of ..."

UPDATE: I'm confused. "qualified name" is different from qualified-id. The wording does make sense as-is, but I'd still just say "name".

Given this clarification, the original issue here (add "if and only if") seems plausible; what do you think?

@jensmaurer jensmaurer changed the title [temp.res#general-5] Not precise [temp.res.general] p5: dependent names in other than type-only context Aug 4, 2021
@xmh0511
Copy link
Contributor Author

xmh0511 commented Aug 4, 2021 •
edited

AFAIK, the term qualified name has a formal definition, which is defined in [basic.lookup.qual#general-2]

A qualified name is

  • a member-qualified name or
  • the terminal name of
  • a qualified-id
  • [...]

In other words, the terminal name of one of the components in the list is called a qualified name, IMO, [temp.res.general] p4 seems to have no problem(a qualified name is the terminal name of ...), at least, there is no conflict here.

In addition, [temp.res.general] p4 in most respects is saying the terminal name of a qualified-id(even if it should be a simple-type-specifier on grammar), which is another #4791 issue.

@opensdh
Copy link
Contributor

opensdh commented Aug 31, 2021

Given this clarification, the original issue here (add "if and only if") seems plausible; what do you think?

I think this rephrasing is an improvement, although this section is going to get rewritten for the "non-expression qualified-id" issue anyway.

@xmh0511
Copy link
Contributor Author

xmh0511 commented Aug 31, 2021

@opensdh For "non-expression qualified-id", the rewritten content is #4793

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@xmh0511 @jensmaurer @opensdh