Die Elementfunktion Outer :: f() ist kein Freund der Klasse Outer :: Inner. Warum?

Question

Nach clang, gcc und vs2013, ist die Funktion Outer::fnicht ein Freund der Klasse Outer::Inner.

struct Outer { 
    void f() {} 
    class Inner { 
     friend void f(); 
     static const int i = 0; 
    }; 
}; 

void f() { int i = Outer::Inner::i; } 

Von [namespace.memdef]/3 I die Funktion Outer::f ein Freund von Outer::Inner, statt ::f, zu sein, weil der Freund Erklärung in seinem Namespace nicht die ersten ist erwarten würde den Namen f enthält.

[Namespace, memdef]/3 (Schwerpunkt liegt mir):

Jeder Name zuerst in einem Namespace deklariert ist ein Mitglied dieser Namespace. Wenn ein Freund Erklärung in einer nicht-lokalen Klasse erste eine Klasse deklariert, Funktion, Klasse-Vorlage oder Funktion Vorlage der Freund ist ein Mitglied der innersten umschließenden Namespace. Die Friend-Deklaration selbst macht den Namen nicht sichtbar für unqualifiziertes Nachschlagen (3.4.1) oder qualifiziertes Nachschlagen (3.4.3). [Hinweis: Der Name des Freundes wird in seinem Namespace sichtbar, wenn eine übereinstimmende Deklaration im Namespacebereich bereitgestellt wird (entweder vor oder nach der Klassendefinition, die Freundschaft gewährt). - Endnote] Wenn eine Freundes- oder Funktionsvorlage aufgerufen wird, kann der Name durch den Namen lookup gefunden werden, der Funktionen aus Namespaces und Klassen berücksichtigt, die den Typen der Funktion Argumente (3.4.2) zugeordnet sind. Wenn der Name in einer Friend-Deklaration weder qualifiziert ist noch eine Template-ID und die Deklaration eine Funktion oder ein elaborated-type-specifier ist, darf die Suche zur Bestimmung, ob die Entität zuvor deklariert wurde, keine Bereiche außerhalb der Innerster einschließender Namespace.

Answer 1

Der erste Teil des Standards, die Sie zitiert sagt (Hervorhebung von mir):

Jeder Name zuerst in einem Namespace erklärt ein Mitglied dieser Namespace ist. Wenn eine Friend-Deklaration in einer nicht lokalen Klasse zuerst eine Klasse oder Funktion deklariert, ist die Friend-Klasse oder -Funktion ein Member des innersten einschließenden Namespace.

Sie gehen davon aus, dass eine Klasse dem Namespace entspricht, was nicht korrekt ist.

namespace Outer { 
    void f(); 
    class Inner { 
     friend void f(); 
     static const int i = 0; 
    }; 
} 

void Outer::f() { int i = Outer::Inner::i; } 

sollte funktionieren. Um die Klassenmitgliedsfunktion als Freund zu verwenden, müssen Sie Folgendes verwenden:

struct Outer { 
    void f(); 
    class Inner { 
     friend void Outer::f(); 
     static const int i = 0; 
    }; 
}; 

void Outer::f() { int i = Outer::Inner::i; } 

Answer 2

Nach [Namespace.memdef]:

Wenn der Name in einer friend Erklärung weder qualifiziert noch ein Template-id ist und die Erklärung ist eine Funktion oder ein erarbeiteter Typ-Spezifizierer, um die Suche zu bestimmen, ob das Unternehmen zuvor erklärt wurde soll keine Bereiche außerhalb der innersten umschließenden Namensraum berücksichtigen.

Was bedeutet "draußen"? Es könnte bedeuten, dass (1) extern von (wie in allen Bereichen innerhalb des innersten einschließenden Namespaces erlaubt ist, aber keine anderen) oder es (2) ausschließlich (wie in, nur der innerste einschließende Namespace berücksichtigt wird) gemeint ist. Die Formulierung ist möglicherweise mehrdeutig. Jedoch betrachten Sie dieses Beispiel, die von OP ursprünglichen Frage und OP Kommentare zusammengeführt wird:

struct Outer { 
    void f() { } 
    class C { void foo(); }; 

    class Inner { 
     friend class C; 
     friend void f(); 
     static const int i = 0; 
    }; 
}; 

void f() { (void)Outer::Inner::i; }    // compiles on GCC,Clang 
void Outer::C::foo() { (void)Outer::Inner::i; } // compiles on GCC,Clang 

int main() { } 

Basierend auf Formulierung (1), Outer::f und Outer::C sollten Freunde von Inner sein. Basierend auf dem Wortlaut (2), ::f und ::C sollten die Freunde sein. Die eine oder andere Interpretation könnte Sinn ergeben, jedoch enden sowohl GCC als auch Clang mit ::f und Outer::C als Freunde, was offensichtlich keinen Sinn ergibt. Ich habe GCC Bug 66836 und Clang Bug 24088 eingereicht. Entweder sind beide Compiler in der einen oder anderen Richtung falsch, oder es gibt einen Teil des Standards, der diese Logik erklärt, die mir definitiv entgeht. Ich würde nicht gegen Letzteres wetten.