Date: 2006-10-15.00:00:00

[Voted into WP at the October, 2006 meeting.]

Date: 2005-10-15.00:00:00

Proposed resolution (October, 2005):

This issue is resolved by the resolution of issue 372.

Date: 2005-03-15.00:00:00

Note (March, 2005):

Andreas Hommel: I think issue 45 requires an additional change in 11.4.12 [class.nest] paragraph 4:

Like a member function, a friend function (11.8.4 [class.friend]) defined within a nested class is in the lexical scope of that class; it obeys the same rules for name binding as a static member function of that class (11.4.9 [class.static]) and has no special access rights to members of an enclosing class.

I believe the “no special access rights” language should be removed.

Date: 2022-11-20.07:54:16

The proposed resolution for issue 45 inserts the following sentence after 11.8 [class.access] paragraph 1:

A member of a class can also access all names as the class of which it is a member.

I don't think that this is correctly constructed English. I see two possibilities:

1. This is a typo, and the correct change is:

   A member of a class can also access all names of the class of which it is a member.

2. The intent is something more like:

   A member of a nested class can also access all names accessible by any other member of the class of which it is a member.

[Note: this was editorially corrected at the time defect resolutions were being incorporated into the Working Paper to read, “...can also access all the names declared in the class of which it is a member,” which is essentially the same as the preceding option 1.]

I would prefer to use the language proposed for 11.8.8 [class.access.nest]:

A nested class is a member and as such has the same access rights as any other member.

A second problem is with the text in 11.8.4 [class.friend] paragraph 2:

[Note: this means that access to private and protected names is also granted to member functions of the friend class (as if the functions were each friends) and to the static data member definitions of the friend class. This also means that private and protected type names from the class granting friendship can be used in the base-clause of a nested class of the friend class. However, the declarations of members of classes nested within the friend class cannot access the names of private and protected members from the class granting friendship. Also, because the base-clause of the friend class is not part of its member declarations, the base-clause of the friend class cannot access the names of the private and protected members from the class granting friendship. For example,

    class A {
        class B { };
        friend class X;
    };
    class X : A::B {     // ill-formed: A::B cannot be accessed
                         // in the base-clause for X
        A::B mx;         // OK: A::B used to declare member of X
        class Y: A::B {  // OK: A::B used to declare member of X
            A::B my;     // ill-formed: A::B cannot be accessed
                         // to declare members of nested class of X
        };
    };

—end note]

This seems to be an oversight. The proposed change to 11.8.8 [class.access.nest] paragraph 1 would appear to have eliminated the restrictions on nested class access. However, at least one compiler (gcc 3.4.3) doesn't appear to take my view, and continues with the restrictions on access by classes within a friend class, while implementing the rest of the resolution of issue 45.