You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The primary issue here is that foo = 0 matches both member-declarator productions. Secondarily, a declarator by itself is also ambiguous, but that's easily fixed by removing the [opt] from the second production and doesn't lead to two different program interpretations.
We then have:
A brace-or-equal-initializer shall appear only in the declaration of a data member.
A pure-specifier shall be used only in the declaration of a virtual function that is not a friend declaration.
... which make the two mutually exclusive but isn't itself a disambiguation rule.
Utterances like virtual FunctionType f = 0; are valid, so we can't disambiguate based on the syntactic form of the declarator. In practice, implementations disambiguate based on whether decl-specifier-seq declarator declares a name with function type, and I believe that is the intent based on the rule in [temp.spec] that acquiring a function type through a dependent type is ill-formed.
Suggested resolution:
Option 1
Add a disambiguation rule, such as:
The token sequence =0 is treated as a pure-specifier if the type of the declarator-id [dcl.meaning.general] is a function type, and is otherwise treated as a brace-or-equal-initializer. [Note: If the member declaration acquires a function type through template instantiation, the program is ill-formed; see [temp.spec.general].]
... and remove the other ambiguity with a grammar change:
A brace-or-equal-initializer shall appear only in the declaration of a data member or a function. [...]
[...] . A brace-or-equal-initializer appearing in the declaration of a member function shall be of the form =0, and is called a pure-specifier. A pure-specifier shall be used only in the declaration of a virtual function that is not a friend declaration.
Either way, this seems borderline editorial to me.
The text was updated successfully, but these errors were encountered:
jensmaurer
changed the title
[class.mem] missing disambiguation rule for pure-specifier vs brace-or-equal-initializer
CWG2661 [class.mem] missing disambiguation rule for pure-specifier vs brace-or-equal-initializer
Dec 4, 2022
Issue description
We have an ambiguous grammar for member-declarator:
The primary issue here is that
foo = 0
matches both member-declarator productions. Secondarily, a declarator by itself is also ambiguous, but that's easily fixed by removing the [opt] from the second production and doesn't lead to two different program interpretations.We then have:
... which make the two mutually exclusive but isn't itself a disambiguation rule.
Utterances like
virtual FunctionType f = 0;
are valid, so we can't disambiguate based on the syntactic form of the declarator. In practice, implementations disambiguate based on whether decl-specifier-seq declarator declares a name with function type, and I believe that is the intent based on the rule in [temp.spec] that acquiring a function type through a dependent type is ill-formed.Suggested resolution:
Option 1
Add a disambiguation rule, such as:
... and remove the other ambiguity with a grammar change:
Option 2
Change the grammar to remove the ambiguity entirely:
Either way, this seems borderline editorial to me.
The text was updated successfully, but these errors were encountered: