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.spec.general] p2 prevents the valid type combination #4796

Open
xmh0511 opened this issue Aug 6, 2021 · 11 comments · May be fixed by #4834
Open

[dcl.spec.general] p2 prevents the valid type combination #4796

xmh0511 opened this issue Aug 6, 2021 · 11 comments · May be fixed by #4834
Assignees
Labels
cwg Issue must be reviewed by CWG.

Comments

@xmh0511
Copy link
Contributor

xmh0511 commented Aug 6, 2021

unsigned  long  long int const volatile a = 0;

In this declaration, the complete decl-specifier-seq is unsigned long long int const volatile. Where unsigned, long, long, int are all simple-type-specifiers, which in turn are type-specifiers, which are also defining-type-specifiers; While const and volatile are both cv-qualifiers, which are type-specifiers, which are also defining-type-specifiers. Hence, in this complete decl-specifier-seq, the defining-type-specifier appears six times.

However, [dcl.spec.general] p2 says

Each decl-specifier shall appear at most once in a complete decl-specifier-seq, except that long may appear twice.

Obviously, defining-type-specifier appears more than once that are not only long. I think the intent of this rule says each indivisible specifier shall appear at most once except that long may appear twice, I would like to name the indivisible specifier as atomic specifier(e.g., int, long, short, const, virtual, explicit ...). But It's not formal wording, maybe we can use some terms to precisely phrase such the meaning?

@jwakely
Copy link
Member

jwakely commented Aug 6, 2021

"atomic specifier" is a bad suggestion, because of the confusion with C's atomic type specifier.

@jwakely
Copy link
Member

jwakely commented Aug 6, 2021

Obviously, defining-type-specifier appears more than once that are not only long.

But they are different specifiers, which is fine, isn't it? It says "each" decl-specifier and that's true. Each of them appears at most once, except long. I don't see the issue.

@xmh0511
Copy link
Contributor Author

xmh0511 commented Aug 6, 2021

In the grammar tree of decl-specifier [dcl.spec.general] p1, it lists all components that are decl-specifiers, "each decl-specifier" sounds like it says each component in that tree.

As you said, from the perspective of specifiers, they are different specifiers, but from the perspective of decl-specifiers, they are all defining-type-specifiers and appear more than once.

@xmh0511
Copy link
Contributor Author

xmh0511 commented Aug 6, 2021

Analogy, when we say each pm-expression shall appear at most once in ...xxx . What does it mean? Should we consider any direct sub-element categories to pm-expression as a unit or something others? In other words, Does it mean cast-expression shall appear at most once or unary-expression or postfix-expression or each indivisible expression(minimum unit)?

Specifically, given the definition for X as the following

X:

  • eggs
  • sticks
  • balloons
  • flowers

We say each X shall appear at most once in my box. Now, there are two different kinds of eggs(e.g., ostrich egg, duck egg) in this box, we cannot say eggs only appear once in my box merely due to the two eggs have different kinds.

@jensmaurer jensmaurer added the decision-required A decision of the editorial group (or the Project Editor) is required. label Aug 9, 2021
@jensmaurer
Copy link
Member

So, the issue is whether we need to decompose decl-specifier into its parts, and how far that decomposition goes (e.g. are tokens inside decltype also in view?).

@xmh0511
Copy link
Contributor Author

xmh0511 commented Aug 10, 2021

The expression in decltype must be a valid expression, IMO, I think we are not necessary to concern the content contained in decltype at the perspective of [dcl.spec.general] p2, the content of decltype shall obey both the grammar and semantic of an expression. However, decltype-specifier shall only appear once on the top-level of the complete decl-specifier-seq.

I don't figure out a fine way to phrase them except that the wording indivisible decl-specifier, that means the most degree of decomposing the decl-specifier defined in the grammar tree.

@jensmaurer
Copy link
Member

jensmaurer commented Aug 10, 2021

That's all fine, but decltype(static_cast<void (*)(int,int)>(nullptr)) does contain (deep inside) the decl-specifiers "void" and "int" (twice). The phrasing needs to be such that those are not considered for the general decl-specifier prohibition.

@xmh0511
Copy link
Contributor Author

xmh0511 commented Aug 10, 2021

void (*)(int,int) is a type-id where void is in the type-specifier-seq, which has a more restrictive requirement.
[dcl.type.general] p2

As a general rule, ..., at most one type-specifier is allowed in a type-specifier-seq. The only exceptions to this rule are the following:

the two "int", in my mind, belong to the different complete decl-specifier-seqs of two parameter-declarations. So, it's fine here. And [dcl.dcl.dcl.pre] p2 also has an extra expound.

Certain declarations contain one or more scopes ([basic.scope.scope]). Unless otherwise stated, utterances in [dcl.dcl] about components in, of, or contained by a declaration or subcomponent thereof refer only to those components of the declaration that are not nested within scopes nested within the declaration.

Even though the parameters have abstract-declarators, but they still obey the above rules due to [dcl.dcl#dcl.decl.general-2]

In all contexts, a declarator is interpreted as given below. Where an abstract-declarator can be used (or omitted) in place of a declarator ([dcl.fct], [except.pre]), it is as if a unique identifier were included in the appropriate place ([dcl.name]).

@zygoloid
Copy link
Member

If this is worth addressing at all, how about:

Each distinct decl-specifier shall appear at most once in a complete decl-specifier-seq, except that long may appear twice.

It seems clear to me that int and unsigned are distinct decl-specifiers even though they both use the same immediate production of decl-specifier. (But I also think the wording as-is is clear; if we wanted the other meaning we'd need to say something like "each form of decl-specifier shall appear at most once".)

@xmh0511
Copy link
Contributor Author

xmh0511 commented Aug 12, 2021

Actually, this issue claims that what is the degree of classification when we say "each decl-specifier". Does it refer to these components that are directly subsumed to decl-specifier? "distinct decl-specifier" may also have the same problem. "storage-class-specifier" is distinguishable with "defining-type-specifier" but "defining-type-specifier" is not distinguishable with itself when in this perspective.

The "adjective" that can exactly express that we shouldn't consider "each decl-specifier" just on the top-level of the grammar tree is significant.

@jensmaurer
Copy link
Member

It is understood that the specification here does not have utmost precision.

  • The decl-specifiers of the decl-specifier-seq need to be decomposed several levels before we can apply the "at most once" check.
  • "shall appear at most once in" has the usual concerns of giving a lexical ("appear") meaning.

While I think the situation is sufficiently clear for type-specifiers and other single-keyword specifiers appearing there, it is less clear for something like:

struct S {
  explicit(false) explicit(true) S(int);
};

Obviously, explicit(false) and explicit(true) are different decl-specifiers, but we seem to be lacking words to make this declaration ill-formed.

@jensmaurer jensmaurer self-assigned this Aug 21, 2021
@jensmaurer jensmaurer 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 Nov 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cwg Issue must be reviewed by CWG.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants