Errors of "additional qualification". How is guaranteed by the Standard?

Question

This similar ill-fated question received comments and short answers, before it was closed, about: how language is defined. Here I ask for evidence in C ++ Standard, which is so defined.

gcc 4.8.1 and clang 3.3, with default diagnostic parameters or more strict, give errors for additional qualifications or explicit code, for example:

struct x { int x::i; // Error: gcc/clang: "extra" }; int ::y; // Error: gcc: "explicit", clang: "extra" 

gcc diagnosed such errors since v4.1. But popular compilers are not unanimous about these errors. MSVC ++ 2012 (Nov CTP) gives an error in int ::y; , but even with /Wall does not give any diagnostics at all int x::i; - the kind of case that the ill-fated questionnaire raised - and this difference involves discussion by the MS compiler.

How are these errors guaranteed by the Standard, if any? References to C ++ 11 Standard will suffice.

The answer may be "They follow from grammar." In that case, try to show how they follow from the grammar and feel free to use the Standard Grammar Classifications. I have a copy and re-read it to understand the explanation.

Answer 1

A qualified name in C ++ should always refer to a previously declared name. This is indicated in sections 8.3 and 3.4.3.2.

You cannot first declare a variable or member using a qualified name - this will result in a "cannot resolve" compiler error. Such qualifiers are intended to be used for re-publication. Therefore, the requirement is that these names find previously declared objects.

Answer 2

This is a bug in the Microsoft compiler to allow x::i in the definition of struct x . There are several of these errors in the MSVC interface, and they were sent to Microsoft, but they close without fixing (see a similar but different error: https://connect.microsoft.com/VisualStudio/feedback/details/783433/c- compiler-accepts-explicit-constructor-call # details and https://connect.microsoft.com/VisualStudio/feedback/details/794504/keyword-struct-before-constructor-name ).

The reason this is unacceptable is because you are trying to declare an int i variable and provide the scope with x::i . The scope of the variable is dictated by where it is declared, so an attempt to declare something using the scope specification tries to declare it somewhere else, which is invalid.