http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32204
--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-10-27
13:13:13 UTC ---
(In reply to comment #8)
> In MSVC's defense, the standard is vague (or insufficient) in this regard for
> 'friend class' declarations. It says:
>
> "If a friend declaration appears in a local class (9.8) and the name specified
> is an unqualified name, a prior declaration is looked up without considering
> scopes that are outside the innermost enclosing non-class scope."
> ...
> "For a friend class declaration, if there is no prior declaration, the class
> that is specified belongs to the innermost enclosing non-class scope, but if
> it
> is subsequently referenced, its name is not found by name lookup until a
> matching declaration is provided in the innermost enclosing nonclass scope."
That wording only applies to local classes, so is irrelevant here. See 7.3.1.2
for the wording that covers non-local classes.
> The standard *should* specify whether the 'friend class declaration' case
> applies to qualified names. For example:
A friend class declaration using qualified name can't introduce a new name, it
can only refer to an existing class, so there must be a prior declaration. See
footnote 95 from 7.3.1.2/3, which says that a friend declaration that first
declares a class must be unqualified.
> namespace ns {
> class NSClass {
> friend class ::SomeGlobalClass;
> };
> }
>
> Since ::SomeGlobalClass is qualified (via scope resolution operator) it
> explicitly belongs to the global namespace.
Yes, but a prior declaration in the global namespace must exist.
> However, the standard says that it
> shall "belong to the innermost enclosing non-class scope", which is a
> contradiction (or nonsense).
No, you've misread the standard.
I think the standard covers your case, GCC behaves correctly here.
This bug report is for a different case anyway, this is not the right place to
discuss it.
