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

Proposed resolution (October, 2005):

1. Change the second bullet of 11.8 [class.access] paragraph 1 as indicated:

   • protected; that is, its name can be used only by members and friends of the class in which it is declared, and by members and friends of classes derived from this class by classes derived from that class, and by their friends (see 11.8.5 [class.protected]).

2. Change 11.8 [class.access] paragraph 2 as indicated:

   A member of a class can also access all the names declared in the class of which it is a member to which the class has access.

3. Change 11.8 [class.access] paragraph 6 as indicated:

   All access controls in 11.8 [class.access] affect the ability to access a class member name from a particular scope. The access control for names used in the definition of a class member that appears outside of the member's class definition is done as if the entire member definition appeared in the scope of the member's class. For purposes of access control, the base-specifiers of a class and the definitions of class members that appear outside of the class definition are considered to be within the scope of that class. In particular...

4. Change the example and commentary in 11.8 [class.access] paragraphs 6-7 as indicated:

   [Example:

       class A {
         typedef int I; // private member
         I f();
         friend I g(I);
         static I x;
       protected:
         struct B { };
       };
   
       A::I A::f () { return 0; }
       A::I g(A::I p = A::x);
       A::I g(A::I p) { return 0; }
       A::I A::x = 0;
   
       struct D: A::B, A { };
   

   Here, all the uses of A::I are well-formed because A::f and A::x are members of class A and g is a friend of class A. This implies, for example, that access checking on the first use of A::I must be deferred until it is determined that this use of A::I is as the return type of a member of class A. Similarly, the use of A::B as a base-specifier is well-formed because D is derived from A, so access checking of base-specifiers must be deferred until the entire base-specifier-list has been seen. —end example]

5. In 11.8.4 [class.friend] paragraph 2, replace the following text:

   Declaring a class to be a friend implies that the names of private and protected members from the class granting friendship can be accessed in declarations of members of the befriended class. [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]

   with:

   Declaring a class to be a friend implies that the names of private and protected members from the class granting friendship can be accessed in the base-specifiers and member declarations of the befriended class. [Example:

       class A {
         class B { };
         friend class X;
       };
   
       struct X: A::B {   // OK: A::B accessible to friend
         A::B mx;         // OK: A::B accessible to member of friend
         class Y {
           A::B my;       // OK: A::B accessible to nested member of friend
         };
       };
   

   —end example]

6. Change the last sentence of 13.4 [temp.arg] paragraph 3 as indicated:

   For a template-argument of that is a class type or a class template, the template definition has no special access rights to the inaccessible members of the template argument type. template-argument. [Example:

       template <template <class TT> class T> class A {
         typename T<int>::S s;
       };
   
       template <class U> class B {
       private:
         struct S { /* ... */ };
       };
   
       A<B> b;    // ill-formed, A has no access to B::S
   
   

   —end example]

7. Change 11.4.12 [class.nest] paragraph 4 as indicated:

   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]), but it and has no special access rights to members of an enclosing class.

(Note: this resolution also resolves issues 494 and 500.)

Notes from the April, 2005 meeting:

The 10/2004 resolution is not sufficient to implement the CWG's intent to allow these examples: 11.8 [class.access] paragraph 1 grants protected access only to “members and friends” of derived classes, not to their base-specifiers. The resolution needs to be extended to say either that access in base-specifiers is determined as if they were members of the class being defined or that access is granted to the class as an entity, including its base-specifiers. See also issue 500, which touches on the same issue and should be resolved in the same way.

Proposed resolution (October, 2004):

1. Change the last sentence of 13.4 [temp.arg] paragraph 3 as indicated:

   For a template-argument of that is a class type or a class template, the template definition has no special access rights to the inaccessible members of the template argument type template-argument. [Example:

       template <template <class TT> class T> class A {
          typename T<int>::S s;
       };
   
       template <class U> class B {
          private:
          struct S { /* ... */ };
       };
   
       A<B> b;   // ill-formed, A has no access to B::S
   

   —end example]

2. Insert the following as a new paragraph after the final paragraph of 11.8 [class.access]:

   The access of names in a class base-specifier-list are checked at the end of the list after all base classes are known. [Example:

       class A {
         protected:
            typedef int N;
       };
   
       template<typename T> class B {};
   
       template<typename U> class C : public B<typename U::N>, public U {};
   
       C<A> x;  // OK: A is a base class so A::N in B<A::N> is accessible
   

   —end example]

Notes from October 2003 meeting:

We decided it makes sense to delay the access checking for the base class specifiers until the opening brace of the class is seen. In other words, the base specifiers will be checked using the full access available for the class, and the order of the base classes is not significant in that determination. The implementors present all said they already had code to handle accumulation of delayed access checks, because it is already needed in other contexts.

Proposed Resolution (October 2002):

Change the last sentence of 13.4 [temp.arg] paragraph 3 from:

For a template-argument of class type, the template definition has no special access rights to the inaccessible members of the template argument type.

For a template-argument that is a class type or a class template, the template definition has no special access rights to the members of the template-argument. [Example:

  template <template <class TT> class T> class A {
    typename T<int>::S s;
  };

  template <class U> class B {
    private:
    struct S { /* ... */ };
  };

  A<B> b;   // ill-formed, A has no access to B::S

-- end example]

Daniel Frey posts on comp.std.c++ in July 2003: I just read DR 372 and I think that the problem presented is not really discussed/solved properly. Consider this example:

  class A {
  protected:
     typedef int N;
  };

  template< typename T >
  class B
  {};

  template< typename U >
  class C : public U, public B< typename U::N >
  {};

  C< A > x;

The question is: If C is derived from A as above, is it allowed to access A::N before the classes opening '{'?

The main problem is that you need to access U's protected parts in C's base-clause. This pattern is common when using policies, Andrei's Loki library was bitten by it as he tried to make some parts of the policies 'protected' but some compilers rejected the code. They were right to reject it, I think it's 11.8.4 [class.friend]/2 that applies here and prevents the code above to be legal, although it addresses a different and reasonable example. To me, it seems wrong to reject the code as it is perfectly reasonable to write such stuff. The questions are:

• Do you agree it's reasonable?
• Is it a DR or is it a request for an extension?
• Is DR 372 the right place to address it or shall it be a new DR?

Steve Adamczyk: In other words, the point of the issue is over what range access derived from base class specifiers is granted, and whether any part of that range is the base specifier list itself, either the parts afterwards or the whole base specifier list. (Clark Nelson confirms this is what he was asking with the original question.) Personally, I find it somewhat disturbing that access might arrive incrementally; I'd prefer that the access happen all at once, at the opening brace of the class.

I'm not really sure what the standard says about this. Personally, I'd like for it to be ill-formed, but I can't find any words that I can interpret to say so.

  template<class T>
  class X
  {
  protected:
    typedef T Type;
  };
  template<class T>
  class Y
  {
  };
  template<class T,
           template<class> class T1,
           template<class> class T2>
  class Z:
    public T2<typename T1<T>::Type>,
    public T1<T>
  {
  };
  Z<int, X, Y> z;

John Spicer: I don't think the standard really addresses this case. There is wording about access checking of things used as template arguments, but that doesn't address accessing members of the template argument type (or template) from within the template.

This example is similar, but does not use template template arguments.

  class X {
  private:
    struct Type {};
  };
  template <class T> struct A {
    typename T::Type t;
  };
  A<X> ax;

This gets an error from most compilers, though the standard is probably mute on this as well. An error makes sense -- if there is no error, there is a hole in the access checking. (The special rule about no access checks on template parameters is not a hole, because the access is checked on the type passed in as an argument. But when you look up something in the scope of a template parameter type, you need to check the access to the member found.)

The logic in the template template parameter case should be similar: anytime you look up something in a template-dependent class, the member's access must be checked, because it could be different for different template instances.