Given the following code: int x; int main() { int(::x); //does not compile int(::x + 2); //compiles } gcc 4.9 will compile it without an error while gcc 4.8.x and clang 3.4 will generate an error. For gcc 4.8.x the error is: error: invalid use of qualified-name '::x' int(::x); //does not compile ^ and clang gives the following error: error: definition or redeclaration of 'x' cannot name the global scope int(::x); //does not compile ~~^ as far as I can tell both gcc 4.8.x and clang are correct here based on my reading of section 8.3 paragraph 6: int(::x) ; is equivalent to: int ::x ; which is not valid. The problem originally cam up in the following Stackoverflow question: http://stackoverflow.com/questions/24623071/is-typex-valid
(In reply to Shafik Yaghmour from comment #0) > as far as I can tell both gcc 4.8.x and clang are correct here based on my > reading of section 8.3 paragraph 6: > > int(::x) ; > > is equivalent to: > > int ::x ; > > which is not valid. Current G++ and EDG both treat it as the valid expression (int)::x
I am happy to be mistaken here, but it seems like section 6.8 paragraph 1 applies, for example if we have the following: int(y) = 10; it is being treated as a declaration not a cast and further more section 6.8 comments on an ill-formed example and says: This is of course ill-formed for semantic reasons, but that does not affect the syntactic analysis. so even though: int(::x); would be ill-formed we are forced to treat it as a declaration and not a function style cast.
This is a GCC bug (or extension). Expression / declaration disambiguation is purely syntactic, and 'int(::x);' conforms to the grammar for a simple-declaration. I've also reported the bug to EDG.
Confirmed then. Thanks, Richard.
Somewhat related: http://stackoverflow.com/questions/28955859 struct Foo { enum { bar }; explicit Foo(int){} }; struct Baz { explicit Baz(Foo){} }; Baz b(Foo(Foo::bar)); // 1 Line #1 should be ill-formed because it fits the grammar for a function declaration and is disambiguated as such. GCC considers it a variable declaration instead. Clang rejects it - see https://llvm.org/bugs/show_bug.cgi?id=4594.