The most annoying parsing with a qualified identifier - or not?

Consider:

struct Foo { enum { bar }; explicit Foo(int){} }; struct Baz { explicit Baz(Foo){} }; Baz b(Foo(Foo::bar)); // #1 

Is line # 1 the most annoying parsing, even though Foo::bar is a qualified identifier and cannot be a valid parameter name? Clang and GCC disagree ; which compiler is right?

+5
source share
1 answer

Klang is right.

It is somewhat surprising that the grammar of the parameter declaration allows both qualified and unqualified identifiers, since it accepts all declarators:

 parameter-declaration: attribute-specifier-seq_opt decl-specifier-seq declarator attribute-specifier-seq_opt decl-specifier-seq declarator = initializer-clause attribute-specifier-seq_opt decl-specifier-seq abstract-declarator_opt attribute-specifier-seq_opt decl-specifier-seq abstract-declarator_opt = initializer-clause 

and the grammar for the declarator allows both qualified and unqualified identifiers. For better or worse, the "no qualified-id for function parameters names" rule is a semantic rule, although you can easily write a grammar to declare parameters that directly excludes qualified identifiers.

As with this question , the disambiguation rule is purely syntactic, and since

 Baz b(Foo(Foo::bar)); 

can be parsed as a function declaration, so it is parsed, although in this case the ambiguity leads to the fact that it is impossible to compile.

See also error 4594 .

+8
source

Source: https://habr.com/ru/post/1215026/


All Articles