Path: csiph.com!news.mixmin.net!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c++ Subject: Re: Compilers still disagree on the Most Vexing Parse Date: Wed, 26 Jul 2023 02:31:12 -0700 Organization: A noiseless patient Spider Lines: 63 Message-ID: <86r0ovqasf.fsf@linuxsc.com> References: <_%9jM.5489$HtC8.1764@fx36.iad> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: dont-email.me; posting-host="5ba297a04e2080c4db730e1e3158367c"; logging-data="1542684"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19u62J6bk1I9Bg4tN8c1GWxPzxA7QZDV1w=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:oTL+5WNuB7Lb8bDgzpe8r+spPNY= sha1:zWHvj0SOOY3Xth62KwB7GfCadXk= Xref: csiph.com comp.lang.c++:91186 Pavel 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.