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

Andrey Tarasevich wrote:
> 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"?

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

Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> writes:

> Andrey Tarasevich wrote:
>
>> 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"?
>
> 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.

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