6

Consider:

struct Foo {
     enum { bar };
     explicit Foo(int){}
};

struct Baz { explicit Baz(Foo){} };

Baz b(Foo(Foo::bar)); // #1

Is line #1 the most vexing parse, even though Foo::bar is a qualified-id and can't possibly be a valid parameter name? Clang and GCC disagree; which compiler is correct?

T.C.
  • 133,968
  • 17
  • 288
  • 421

1 Answers1

9

Clang is right.

Somewhat surprisingly, the grammar for parameter-declaration permits both qualified- and unqualified-ids, because 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 a declarator permits both qualified- and unqualified-ids. The "no qualified-id for function parameter names" rule, for better or worse, is a semantic rule, even though it is easily possible to write a grammar for parameter-declaration that excludes qualified-ids directly.

Just like the situation in this question, the disambiguation rule is purely syntatic, and since

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

can syntatically be parsed as a function declaration, it is so parsed, even though the disambiguation in this case results in something that can never compile.

See also clang bug 4594.

Community
  • 1
  • 1
T.C.
  • 133,968
  • 17
  • 288
  • 421
  • 1
    I was going to say this looks very familiar ;-) so who is correct `gcc` or `clang`, it should be obvious but it would be nice to be more explicit. – Shafik Yaghmour Mar 10 '15 at 04:22
  • @ShafikYaghmour variations on the same theme, to be sure :) This case did surprise me, and I'm usually quite good at spotting MVPs... – T.C. Mar 10 '15 at 04:24
  • This answer is based on the assumption that language grammar (language syntax) is described by the formal grammar (as presented Annex A) only. And that all other restrictions/requirements listed additionally in the text of the standard are not syntactic (they are semantic, as the answer claims). This could be true, but this strikes me as a surprisingly inefficient approach to describing language syntax. It is typically very inefficient to attempt to describe the whole syntax by the formalized grammar alone. – AnT stands with Russia Jan 31 '19 at 01:28
  • Being able to separate syntax rules into those that would go into the grammar, and those that will be described in plain text *accompanying the grammar* makes for a much more flexible, compact and readable specification. I would expect language standard authors to be free to "pull" some rules from the formal grammar and replace them with textual description and vice versa. The language *syntax* would be described by the combination of the formal grammar and its accompanying syntactic rules in plain text. This is how I would regard the prohibition to use qualified names as parameter names. – AnT stands with Russia Jan 31 '19 at 01:29
  • I.e. it is a purely *syntactic* rule that was deemed more suitable for textual description (to avoid over-complicating the grammar). (Yes, I understand that it is probably not too difficult to embed this requirement into the formal grammar, but anyway...) For which reason I'd perceive the GCC's behavior as the "more logical" in this case: GCC understands (supposedly correctly) that "to consider any construct that could possibly be a declaration a declaration" requirement involves checking "no qualified names as parameter names" rule as well. – AnT stands with Russia Jan 31 '19 at 01:32