Compilers still disagree on the Most Vexing Parse

[Andrey Tarasevich]

Consider this

namespace N { const int C = 42; }

struct S { S(int) {} };

int main()
{
S s(S(N::C));
}

Both Clang and MSVC reject the declaration in `main`, since they insist
on interpreting it as a function declaration, and subsequently complain
about invalid parameter name syntax: qualified name is not allowed as a
function parameter name.

GCC quietly accepts the declaration inside `main` and treats it as an
object declaration. Of course, GCC also has to make an effort to
interpret it as a function declaration, but apparently when that attempt
fails, it falls back to interpreting it as an object declaration.

The standard says

http://eel.is/c++draft/dcl.ambig.res#1
1 The ambiguity arising from the similarity between a function-style
cast and a declaration mentioned in [stmt.ambig] can also occur in the
context of a declaration. In that context, the choice is between an
object declaration with a function-style cast as the initializer and a
declaration involving a function declarator with a redundant set of
parentheses around a parameter name. Just as for the ambiguities
mentioned in [stmt.ambig], the resolution is to consider any construct,
such as the potential parameter declaration, that could possibly be a
declaration to be a declaration.

I presume that the above "could possibly be" refers to purely
grammar-level correctness of the construct. And general declarator
syntax in the grammar actually allows qualified names in declarators (we
use them, for example, when defining class members outside of class
definition). So, I presume this is why Clang and MSVC believe that this
falls within the boundaries of that "could possibly be".

What about GCC, which accepts the code? Is this a consequence of GCC
sticking to a different interpretation of that "could possibly be"? Or
is this a GCC-specific "extension"?

--
Best regards,
Andrey

[Pavel]

I am guessing, the former. I did not find a documented extension, even
though the most vexing parse is documented with several examples; so
leaving such an extension undocumented seems unlikely.

Also, my immediate interpretation of "could possibly be" is that it is
equivalent to "could be a part of a legal C++ program" and a legal C++
program has to be compilable. In other words, if the program can be
compiled in more than one ways, there is an ambiguity; else, there is no
ambiguity and there is nothing to resolve. Long story short, I am with
gcc here.

HTH,
-Pavel

[Tim Rentsch]

Humorous that the resolution of an ambiguity is written in such
a way that the disambiguiting condition itself has an ambiguity.